<br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Ivan KrstiŠ</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sep 6, 2007, at 4:09 AM, Martin v. L÷wis wrote:<br>> There are more issues, of course: some countries restrict the use<br>> of cryptography. France is given as an example: you need to register<br>> your cryptography keys with the government (SCSSI) before you can
<br>> use confidentiality-oriented algorithms, IIUC.<br><br>This gets at what most interests me -- namely, whether there's a<br>strong legal barrier to including more crypto with Python than just<br>the hashes we have at the moment. It sounds like the answer is 'yes',
<br>but what are the details?</blockquote><div><br>fwiw hashes are not cryptography.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The distribution size issue can be mitigated by a reasonable choice<br>of supported primitives. I don't think we need to ship the crypto<br>kitchen sink with Python; we can disqualify known-broken algorithms<br>that many libraries still ship, etc.
</blockquote><div><br>I see nothing wrong with leaving pycrypto as an add-on library as most things don't need it. <a href="http://www.amk.ca/python/code/crypto">http://www.amk.ca/python/code/crypto</a>.<br><br>The pycrypto API is is very nice. But if we were to consider it for the standard library I'd prefer it just link against OpenSSL rather than use its own C implementations and just leave platforms without ssl without any crypto.
<br><br>Besides the chances are that most programmers seeing a crypto library will misuse it and gain a false sense of security on what they've done. ;)<br><br></div></div>