diff options
Diffstat (limited to 'pipermail/pycrypto/2013q1/000652.html')
| -rw-r--r-- | pipermail/pycrypto/2013q1/000652.html | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/pipermail/pycrypto/2013q1/000652.html b/pipermail/pycrypto/2013q1/000652.html new file mode 100644 index 0000000..8a928ae --- /dev/null +++ b/pipermail/pycrypto/2013q1/000652.html @@ -0,0 +1,207 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HTML> + <HEAD> + <TITLE> [pycrypto] Hash: Remove "oid" attributes; add "name" attribute + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:pycrypto%40lists.dlitz.net?Subject=Re%3A%20%5Bpycrypto%5D%20Hash%3A%20Remove%20%22oid%22%20attributes%3B%20add%20%22name%22%20attribute&In-Reply-To=%3C20130218075848.GA4050%40goedel.dlitz.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <style type="text/css"> + pre { + white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */ + } + </style> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000650.html"> + <LINK REL="Next" HREF="000656.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[pycrypto] Hash: Remove "oid" attributes; add "name" attribute</H1> + <B>Dwayne Litzenberger</B> + <A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=Re%3A%20%5Bpycrypto%5D%20Hash%3A%20Remove%20%22oid%22%20attributes%3B%20add%20%22name%22%20attribute&In-Reply-To=%3C20130218075848.GA4050%40goedel.dlitz.net%3E" + TITLE="[pycrypto] Hash: Remove "oid" attributes; add "name" attribute">dlitz at dlitz.net + </A><BR> + <I>Sun Feb 17 23:58:48 PST 2013</I> + <P><UL> + <LI>Previous message: <A HREF="000650.html">[pycrypto] Remove DSA because 1024bit is not safe +</A></li> + <LI>Next message: <A HREF="000656.html">[pycrypto] Hash: Remove "oid" attributes; add "name" attribute +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#652">[ date ]</a> + <a href="thread.html#652">[ thread ]</a> + <a href="subject.html#652">[ subject ]</a> + <a href="author.html#652">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>[Reposted from 'Hash: Remove "oid" attributes; add "name" attribute' + <A HREF="https://github.com/dlitz/pycrypto/commit/a3ec589b8dcd1c86ddd5f35666e74aa3230801b5">https://github.com/dlitz/pycrypto/commit/a3ec589b8dcd1c86ddd5f35666e74aa3230801b5</A>]: + +Legrandin wrote: + +><i>Hi Dwayne, +</I>><i> +</I>><i>The Object ID is an identifier assigned by (inter)national standard +</I>><i>bodies (NIST) or recognized private organizations (RSA Inc, Teletrust) +</I>><i>to the hash algorithm for use in all the several crypto protocols based +</I>><i>on ASN.1 (PKCS#1 signatures, PKCS#7/CMS, PKCS#8 private key +</I>><i>encapsulation, SSL/TLS, CA certificates, etc). Nothing stops one from +</I>><i>also using without ASN.1, as a stand-along numerical string guaranteed +</I>><i>to be unique. +</I>><i> +</I>><i>The fact that a few other protocols don't use it (and prefer to have +</I>><i>their own internal identifiers, and therefore not leverage work done by +</I>><i>others already) does not look to me as a reason to isolate it in the +</I>><i>PKCS#1v1.5 signature module, considering that protocols that use it are +</I>><i>the majority, and all hashes currently in pycrypto have it (being them +</I>><i>all quite mature). +</I>><i> +</I>><i>The attribute could also remained undefined for those experimental hash +</I>><i>that pycrypto ever introduced but that don't have any Object ID +</I>><i>assigned yet (e.g. Salsa20 maybe?). That would just mean that the hash +</I>><i>cannot be used to make PKCS#1v1.5 signatures (which makes sense). If +</I>><i>the OID exists, it can be added to the module. It it doesn't, it is not +</I>><i>defined. +</I> +My response: + + Be very careful with your use of Object Identifiers. In many cases there are a + great many OIDs available for the same algorithm, but the exact OID you're + supposed to use varies somewhat. + -- Peter Gutmann, X.509 Style Guide, <A HREF="http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt">http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt</A> + +><i> Protocols that use [OIDs] are the majority +</I> +Really? The only widely-used protocols I can think of are SNMP (which +is irrelevant here), LDAP (also irrelevant), and the CMS/TLS/PKCS +protocol suite. SSH doesn't use them, OpenPGP doesn't use them, DNSSEC +doesn't use them, OAuth doesn't use them, OpenID doesn't use them, DKIM +doesn't use them, and I'm pretty sure that IPsec/IKEv1/IKEv2 don't use +them. Of the protocols that do use them, which ones actually use the +OIDs listed in this commit, rather than some ciphersuite identifier like +pbeWithSHA1AndDES-CBC? Have there been any major new crypto protocols +designed in the last decade that use these OIDs? That use ASN.1? + +This is going to be a bit of a long rant. + +OIDs and ASN.1 are legacy ITU-T crap, and the protocols built around +them are overcomplicated and error-prone. The only reason why I merged +any ASN.1 stuff at all is because PKCS#1 uses it. PKCS#1 is a bit of a +special case, because it's basically synonymous with RSA; It's even used +protocols that don't otherwise use ASN.1 use PKCS#1. + +I think it was you who convinced me that the ASN.1 used by PKCS#1 was +simple enough that it wouldn't lead to an endless series of bugs. Even +so, you *still* got it wrong, as described in LP#1119552 [1] . I'm not +blaming you; I'm blaming ASN.1 for being such a terrible, complicated, +obfuscatory way to define and describe data formats. Hell, the only +reason why you got it wrong was because *so many other people got it +wrong early on that the spec was modified to accommodate their errors*. +And PKCS#1 is a much *simpler* use-case of ASN.1 compared to the rest of +the CMS/TLS/PKCS suite... + +In contrast, PyCrypto *needs* to be kept simple, because we simply don't +have the developer resources to create a secure CMS/TLS/PKCS +implementation. Even if we had the resources, getting it right is +tricky enough that we *shouldn't* try to make yet another +implementation---especially not one that's Python-specific. It would be +better to pool our limited resources with other FOSS crypto developers +to improve the existing implementations, or maybe to try to recruit them +to work on a new project that would become the successor to the existing +implementations. One more insecure, resource-starved FOSS CMS/TLS/PKCS +implementation is not good for users. + +OpenSSL exists today, and there are several ways to use it from Python. +The purpose of PyCrypto is not to reimplement everything that OpenSSL +already does. What would be gained by doing that? If we just wanted to +make a nicer, more Pythonic API for OpenSSL, we could just add OpenSSL +as a dependency and be done with it. (Python itself already uses +OpenSSL for hashlib, so it's not unprecedented.) + +PyCrypto is used by a lot of folks who are either implementing +recently-created protocols (i.e. *not* CMS/TLS/PKCS), or who +are---rightly or wrongly---creating new protocols. One of my goals with +PyCrypto has been to improve their chances of building something secure, +and to me that means that I should steer people to simpler, +easy-to-implement building blocks like OpenPGP and SSH, not complex, +error-prone things like ASN.1/CMS/TLS/X.509/PKCS#12. + +I want to avoid turning PyCrypto into something that treats CMS/TLS/PKCS +as the gold standard and everything else as a second-class citizen. +There have already been a few cases of that (for example, the "oid" +attribute here, and the "pkcs" parameter to RSA.exportKey), and I see +those things as oversights that need to be fixed, not things that I want +to entrench further. + +I see that you've been building a PKCS#8 implementation in your fork of +the PyCrypto repo. I can only assume that you eventually plan to build +a PKCS#7/CMS implementation, too. That's fine, but seeing things like +`algos = { 'PBKDF2WithHMAC-SHA1AndDES-EDE3-CBC' : +_PBES2_Factory(_PBKDF2_Factory(), _DES_EDE3_CBC_Factory()) }` convinces +me that it's beyond the scope of what I want to include in PyCrypto, +unless it were in a well-isolated subdirectory that could be easily +split into a separate package if the maintenance became too burdensome +for me. At a minimum, we'd need to agree that the string "X.509" +doesn't belong in the module that implements the raw RSA primitive. + +You've done a lot of good work and I appreciate your contributions, but +IMHO you're embedding the PKCS stuff too deeply into the core of +PyCrypto when I'd prefer to see it in separate subdirectory, or even a +separate library. This is partly my fault: I was a bit too anxious to +merge the PKCS#1 stuff after being absent for a while, so I didn't pay +close enough attention to the API changes (even though the API is really +what differentiates PyCrypto from other libraries). In the future, I'm +going to try to be more picky upfront about the API, to avoid +backpedaling like I'm doing right now with the .oid stuff. + +As I see it, the PKCS1 stuff probably should have been consolidated into +something like Crypto.Protocol.PKCS1. Going forward, the PKCS8 stuff +should probably go into something like Crypto.Protocol.PKCS8, and a +future OpenPGP package could go into Crypto.Protocol.OpenPGP. +RSA.importKey and RSA.exportKey should probably be deprecated and moved +into the PKCS1 and PKCS8 packages, respectively. + +The exact names of the subtrees are debatable, but the idea is create a +clear separation between the primitives and the protocols that use them, +rather than mixing them all together. This is particularly important +for the hash modules, since those could eventually become thin wrappers +around the standard hashlib library---I doubt that would ever happen if +we insisted on attaching extraneous things like OIDs to them. + +Again, sorry for the long message, but I wanted to explain my thinking +as clearly as possible. Let me know what you think. + +Cheers, +- Dwayne + +[1] <A HREF="https://bugs.launchpad.net/pycrypto/+bug/1119552">https://bugs.launchpad.net/pycrypto/+bug/1119552</A> + +-- +Dwayne C. Litzenberger <<A HREF="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">dlitz at dlitz.net</A>> + OpenPGP: 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7 +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000650.html">[pycrypto] Remove DSA because 1024bit is not safe +</A></li> + <LI>Next message: <A HREF="000656.html">[pycrypto] Hash: Remove "oid" attributes; add "name" attribute +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#652">[ date ]</a> + <a href="thread.html#652">[ thread ]</a> + <a href="subject.html#652">[ subject ]</a> + <a href="author.html#652">[ 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> |