Crypto

Folks,

Here's what came out for Mozilla, which, I hope you'll pardon my
saying so, is a teensy tad more widely used than PostgreSQL has any
plans to become.

http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm

I suggest that we start by putting secure hashing algorithms into the
core distribution so, should MD5 ever break, we have real
alternatives, and not done in a panic.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter wrote:
> I suggest that we start by putting secure hashing algorithms into the
> core distribution so, should MD5 ever break, we have real
> alternatives, and not done in a panic.
>
>
>

Doing that now would be quite premature. Which algorithm would we choose?

And there is no urgency at all about it, since AIUI an attack on our use
of it would require a preimage attack:

At the time of this writing, there are no practical preimage
attacks, meaning that if your use of hashes is only susceptible to
preimage attacks, even MD5 is just fine because at attacker would
have to make 2^128 guesses, which will be infeasable for many
decades (if ever). (quoted from <http://www.vpnc.org/hash.html>)

The time for us to look at this again is more properly when the NIST
SHA-3 competition ends, I believe. That's at least a couple of years
away. See <http://csrc.nist.gov/groups/ST/hash/timeline.html>

As for the suggestion that we should put other crypto functions into the
core, AIUI the reason not to is not to avoid problems with US Export
Regulations (after all, we've shipped source tarballs with it for many
years, including from US repositories), but to make it easier to use
Postgres in places where use of crypto is illegal. What benefit would we
gain from making general crypto part of the core?

cheers

andrew

On Sat, Sep 19, 2009 at 11:50:35AM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>> I suggest that we start by putting secure hashing algorithms into the
>> core distribution so, should MD5 ever break, we have real
>> alternatives, and not done in a panic.
>
> Doing that now would be quite premature. Which algorithm would we choose?
>
> And there is no urgency at all about it, since AIUI an attack on our use
> of it would require a preimage attack:
>
> At the time of this writing, there are no practical preimage
> attacks, meaning that if your use of hashes is only susceptible to
> preimage attacks, even MD5 is just fine because at attacker would
> have to make 2^128 guesses, which will be infeasable for many
> decades (if ever). (quoted from <http://www.vpnc.org/hash.html>)
>
>
> The time for us to look at this again is more properly when the NIST
> SHA-3 competition ends, I believe. That's at least a couple of years
> away. See <http://csrc.nist.gov/groups/ST/hash/timeline.html>

OK

> As for the suggestion that we should put other crypto functions into
> the core, AIUI the reason not to is not to avoid problems with US
> Export Regulations (after all, we've shipped source tarballs with
> it for many years, including from US repositories), but to make it
> easier to use Postgres in places where use of crypto is illegal.

To date, I have not found an example of such a place. For the record,
would you or anyone seeing this be so kind as to provide one, along
with some kind of evidence that somewhere, such a law has actually
been enforced?

> What benefit would we gain from making general crypto part of the
> core?

People may wish to encrypt things in the database.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david(at)fetter(dot)org> writes:
> On Sat, Sep 19, 2009 at 11:50:35AM -0400, Andrew Dunstan wrote:
>> What benefit would we gain from making general crypto part of the
>> core?

> People may wish to encrypt things in the database.

That is not an argument why it has to be in core rather than an add-on.

regards, tom lane

I think the same, These are not arguments to include crypto on the core, due to then all users have to think on this aspect to build a simple database, so we would be obligating to the users to use this module.

I´d let this module on the contrib

Regards

"The hurry is enemy of the success: for that reason.......Be patient"

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/

----- Mensaje original -----
De: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Para: "David Fetter" <david(at)fetter(dot)org>
CC: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>
Enviados: Sábado, 19 de Septiembre 2009 6:33:36 GMT -10:00 Hawai
Asunto: Re: [HACKERS] Crypto

David Fetter <david(at)fetter(dot)org> writes:
> On Sat, Sep 19, 2009 at 11:50:35AM -0400, Andrew Dunstan wrote:
>> What benefit would we gain from making general crypto part of the
>> core?

> People may wish to encrypt things in the database.

That is not an argument why it has to be in core rather than an add-on.

regards, tom lane

David Fetter wrote:
>> As for the suggestion that we should put other crypto functions into
>> the core, AIUI the reason not to is not to avoid problems with US
>> Export Regulations (after all, we've shipped source tarballs with
>> it for many years, including from US repositories), but to make it
>> easier to use Postgres in places where use of crypto is illegal.
>>
>
> To date, I have not found an example of such a place. For the record,
> would you or anyone seeing this be so kind as to provide one, along
> with some kind of evidence that somewhere, such a law has actually
> been enforced?
>

There are significant controls in a number of countries. See
<http://rechten.uvt.nl/koops/cryptolaw/cls-sum.htm>.

I am not going to do more research on this - I have better things to do
with my time. The point has been made elsewhere that including general
crypto in core is entirely unnecessary for any purpose we know of. That
along with knowledge that its use is at least restricted in several
countries should surely be argument enough.

This comes up often enough that I'm almost wondering if it deserves an
FAQ entry.

cheers

andrew

On the subject of crypto law - the laws have relaxed significantly in
the last decade to the point where it is now generally safe to export
symmetric encryption up to 128 bits (example: AES), and assymetric
encryption up to 1024 bits (example: RSA). Many countries still require
some sort of license, though, which takes the form of a formal request
"may I export this?" "yes". As a "for example", I received approval from
our company lawyers to re-export the Java runtime with a program we have
which uses exactly 128 bit symmetric and 1024 bit assymetric to all
countries except embargoed countries. Since it makes no sense to do
business in embargoed countries anyways, there is no point in asking at all.

For free / open source software in general, the US has explicit
exemptions for freely available software on the Internet, for the most
part because it is impossible for them to control it. In this situation,
PostgreSQL has a lot more freedom than, say, Oracle, to distribute
crypto. As a for example, Firefox includes crypto to support SSL and
certificate checking. Now, many countries also have *import*
restrictions, so while it's safe to freely export Firefox from the
United States over the Internet, in some countries, it is *illegal* for
their own citizens to encrypt their data beyond a certain level. If such
rules are enforced (I think Australia even had such a rule for a time),
then it would be the citizen doing the import that is affected. At
present, I wonder about the status of such things in China. While in
China, they didn't prevent me from using my high encryption strength VPN
software to access work - was I breaking the law by "importing" the
technology and using it? I don't know, and I didn't really think much
about it at the time.

All this being said - laws change all the time, and the number of
countries involved in the equation each which may or may not have rules
that apply to PostgreSQL at various times, that I still agree with
Andrew - to go from no-crypto to crypto is a huge change that MAY result
in downstream consequences which would adversely effect the success of
PostgreSQL, or may even end up with some PostgreSQL representative in
the chain defending themselves in a court room.

I think it would be best to leave crypto *outside* of core, but make it
an extremely easy to add plugin with "download at your own risk - if you
are unsure whether you are allowed to import crypto into your country,
you are responsible for seeking your own legal counsel."

Java did this with their main software being generally exportable, and
their "unlimited strength" crypto libraries requiring a separate
download with appropriate warnings to keep Sun happy that they would not
be held legally responsible if somebody did misuse the software.

I work for a telecommunications company which requires crypto in most
software components, so this stuff is taken very seriously. The last
thing you want to see on television is a terrorist using an untraceable
"secure" line with your company's brand name on the front, as they lop
off the head of a reporter. There is a level of responsibility required
for such things both from a business perspective and from a ethics
perspective.

Cheers,
mark

On 09/19/2009 01:55 PM, Andrew Dunstan wrote:
>
> David Fetter wrote:
>>> As for the suggestion that we should put other crypto functions into
>>> the core, AIUI the reason not to is not to avoid problems with US
>>> Export Regulations (after all, we've shipped source tarballs with
>>> it for many years, including from US repositories), but to make it
>>> easier to use Postgres in places where use of crypto is illegal.
>>
>> To date, I have not found an example of such a place. For the record,
>> would you or anyone seeing this be so kind as to provide one, along
>> with some kind of evidence that somewhere, such a law has actually
>> been enforced?
>
> There are significant controls in a number of countries. See
> <http://rechten.uvt.nl/koops/cryptolaw/cls-sum.htm>.
>
> I am not going to do more research on this - I have better things to
> do with my time. The point has been made elsewhere that including
> general crypto in core is entirely unnecessary for any purpose we know
> of. That along with knowledge that its use is at least restricted in
> several countries should surely be argument enough.
>
> This comes up often enough that I'm almost wondering if it deserves an
> FAQ entry.
>

--
Mark Mielke<mark(at)mielke(dot)cc>

On Fri, 2009-09-18 at 18:14 -0700, David Fetter wrote:
> Here's what came out for Mozilla, which, I hope you'll pardon my
> saying so, is a teensy tad more widely used than PostgreSQL has any
> plans to become.
>
> http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm
>
> I suggest that we start by putting secure hashing algorithms into the
> core distribution so, should MD5 ever break, we have real
> alternatives, and not done in a panic.

OK, it's late here, but how do you get from that article to a need to
replace MD5?

Le samedi 19 septembre 2009, David Fetter a écrit :
> Folks,
>
> Here's what came out for Mozilla, which, I hope you'll pardon my
> saying so, is a teensy tad more widely used than PostgreSQL has any
> plans to become.
>
> http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+
> Cleared+of+US+Export+Rules.htm
>
> I suggest that we start by putting secure hashing algorithms into the
> core distribution so, should MD5 ever break, we have real
> alternatives, and not done in a panic.

What I see in this article is that a law need to be change in the US...
Something else ? :p

----
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org