Thread: 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@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Do you can comment this altertatives or choices that we have? We can support us in Bruce Schneier[1], Chief Security Technology Officer, BT (schneier@schneier.com) who is one of the person that knows many topics about security in the world. Is a very nice person and allways is to ableto help to people. One of his knowledge areas is the hashing algorithm's desing and study, and we can ask to him sincehis point of view which would be the best algoritm to do this. Regards [1] http://www.schneier.com "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: "David Fetter" <david@fetter.org> Para: "PG Hackers" <pgsql-hackers@postgresql.org> Enviados: Viernes, 18 de Septiembre 2009 15:14:29 GMT -10:00 Hawai Asunto: [HACKERS] 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@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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 susceptibleto preimage attacks, even MD5 is just fine because at attacker would have to make 2^128 guesses, which willbe 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@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.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 aspectto 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@sss.pgh.pa.us> Para: "David Fetter" <david@fetter.org> CC: "Andrew Dunstan" <andrew@dunslane.net>, "PG Hackers" <pgsql-hackers@postgresql.org> Enviados: Sábado, 19 de Septiembre 2009 6:33:36 GMT -10:00 Hawai Asunto: Re: [HACKERS] Crypto David Fetter <david@fetter.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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@mielke.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