<br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Ivan KrstiŠ</b> &lt;<a href="mailto:krstic@solarsail.hcs.harvard.edu">krstic@solarsail.hcs.harvard.edu</a>&gt; 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>&gt; There are more issues, of course: some countries restrict the use<br>&gt; of cryptography. France is given as an example: you need to register<br>&gt; your cryptography keys with the government (SCSSI) before you can
<br>&gt; use confidentiality-oriented algorithms, IIUC.<br><br>This gets at what most interests me -- namely, whether there&#39;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 &#39;yes&#39;,
<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&#39;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&#39;t need it.&nbsp; <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.&nbsp; But if we were to consider it for the standard library I&#39;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&#39;ve done. ;)<br><br></div></div>