summaryrefslogtreecommitdiff
path: root/pipermail/pycrypto/2008q4/000045.html
diff options
context:
space:
mode:
Diffstat (limited to 'pipermail/pycrypto/2008q4/000045.html')
-rw-r--r--pipermail/pycrypto/2008q4/000045.html106
1 files changed, 106 insertions, 0 deletions
diff --git a/pipermail/pycrypto/2008q4/000045.html b/pipermail/pycrypto/2008q4/000045.html
new file mode 100644
index 0000000..ee7d1bd
--- /dev/null
+++ b/pipermail/pycrypto/2008q4/000045.html
@@ -0,0 +1,106 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [pycrypto] the sad state of pycrypto
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20the%20sad%20state%20of%20pycrypto&In-Reply-To=20081109163140.GA28028%40rivest.dlitz.net">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="000041.html">
+ <LINK REL="Next" HREF="000050.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[pycrypto] the sad state of pycrypto</H1>
+ <B>Paul Hoffman</B>
+ <A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20the%20sad%20state%20of%20pycrypto&In-Reply-To=20081109163140.GA28028%40rivest.dlitz.net"
+ TITLE="[pycrypto] the sad state of pycrypto">paul.hoffman at gmail.com
+ </A><BR>
+ <I>Sun Nov 9 13:49:49 CST 2008</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="000041.html">[pycrypto] the sad state of pycrypto
+</A></li>
+ <LI>Next message: <A HREF="000050.html">[pycrypto] the sad state of pycrypto
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#45">[ date ]</a>
+ <a href="thread.html#45">[ thread ]</a>
+ <a href="subject.html#45">[ subject ]</a>
+ <a href="author.html#45">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>On Sun, Nov 9, 2008 at 8:31 AM, Dwayne C. Litzenberger &lt;<A HREF="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">dlitz at dlitz.net</A>&gt; wrote:
+&gt;<i> Really? Many developers still use MD5 in new applications.
+</I>
+MD5 is still perfectly usable in applications that do not rely on the
+collision resistance and only need 128 bits of preimage resistance.
+For example, HMAC-MD5 has been proven to be secure even is the
+collision resistance is near zero. A hashed signature algorithm can
+use MD5 with no problems.
+
+&gt;<i> Overly optimistic developers (or their micro-managing bosses) routinely make
+</I>&gt;<i> design choices favouring speed or portability over security, and it's the
+</I>&gt;<i> _users_ who suffer the consequences.
+</I>
+If someone knows enough about MD5 to know that it is faster than
+SHA-1, or that it is more portable than SHA-1, knows about its
+properties enough to use it.
+
+If you really want the library to be in nanny mode, simply rename the
+function from &quot;MD5&quot; to something like &quot;idontwantyoutouseMD5&quot;. This is
+a serious suggestion. Self-documenting function names are surprisingly
+useful.
+
+&gt;<i> Following your line of reasoning,
+</I>&gt;<i> there was nothing wrong with RandomPool; It was simply being misused---by
+</I>&gt;<i> practically everyone. I disagree, and RandomPool is now deprecated.
+</I>
+That is not my line of reasoning. RandomPool was unsafe at any speed.
+MD5 is safe for many purposes.
+
+&gt;<i> If it's licensed to everyone on an automatic, royalty-free basis, then it's
+</I>&gt;<i> not _encumbered_ by a patent, just _covered_ by a patent.
+</I>
+Some pedants would not slice and dice it that way.
+
+&gt;<i> My understanding was that SHA-224 and SHA-384 had additional patent
+</I>&gt;<i> encumbrances that are did not apply to SHA-256 and SHA-512. That
+</I>&gt;<i> understanding probably came from Wikipedia, and it may be incorrect.
+</I>
+I see nothing in the current version of the Wikipedia page that says
+that, and I have never heard of any such encumbrances. If there were,
+the NSA would be amazingly remiss in filing an IPR statement with the
+IETF for the family as a whole but not those members.
+
+&gt;<i> In any case, SHA-224 and SHA-384 are just weakened versions of SHA-256 and
+</I>&gt;<i> SHA-512, so I'm not inclined to add them without good reason.
+</I>
+I am not a proponent of either function, but I can channel those who
+are. SHA-224 is designed to have &quot;matched impedance&quot; with TripleDES,
+which has 112 bits of strength. Similarly, SHA-384 is matched to
+AES-196. I find the impedance idea goofy, but some folks like it.
+</PRE>
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="000041.html">[pycrypto] the sad state of pycrypto
+</A></li>
+ <LI>Next message: <A HREF="000050.html">[pycrypto] the sad state of pycrypto
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#45">[ date ]</a>
+ <a href="thread.html#45">[ thread ]</a>
+ <a href="subject.html#45">[ subject ]</a>
+ <a href="author.html#45">[ author ]</a>
+ </LI>
+ </UL>
+
+<hr>
+<a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">More information about the pycrypto
+mailing list</a><br>
+</body></html>