Fwd: Re: Crypographically Strong Software Distribution HOWTO
More from Rodney - I'm avoiding the is law relevant? branch of this thread because I think it's wandering off-topic, but can continue in private email if any of the participants think it's likely to be productive. Date: Sat, 07 Jul 2001 08:33:29 -0700 To: Greg Broiles [EMAIL PROTECTED] From: Rodney Thayer [EMAIL PROTECTED] Subject: Re: Crypographically Strong Software Distribution HOWTO (I can't tell where the signal and where the noise is in this thread, so I'll just say this to you, feel free to forward.) PKIX and it's legacy ancestor, X.509, have a 'revocation reason' field in the CRL mechanism. However, it's not used -- but then again Verisign and others don't really use revocation so that's not necessarily a good example. It's more interesting to note that, when people try to ask about revocation reasons, it turns out there's little consensus (e.g. in the IETF community) on the need for revocation reason. I think this is because people haven't really tried to deploy these systems in a practical manner, rather than because of any architectural flaw. At 01:15 PM 7/3/01 -0700, you wrote: Because current systems don't, to my knowledge, allow the creators of revocations to specify the reason(s) for revocation, I wonder if it would be better to rely on short-lived keys or certs which are renewed frequently during a person's membership or association with a group. -- Greg Broiles [EMAIL PROTECTED] Organized crime is the price we pay for organization. -- Raymond Chandler - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
At 02:13 PM 7/3/2001 -0400, V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Because current systems don't, to my knowledge, allow the creators of revocations to specify the reason(s) for revocation, I wonder if it would be better to rely on short-lived keys or certs which are renewed frequently during a person's membership or association with a group. Specifically, a revocation which does not distinguish between stopped working on the project because very busy at new job and left laptop with private key on public transit or discovered installed rootkit on machine storing unencrypted private key does not help people decide whether they can reasonably install old(er) distributions of a software package. If the package was signed by a person who is no longer participating as a builder/distributor, their key should not be current - but that doesn't mean that everything which has been signed with their key should be considered untrusted, as it would be in the case of a key compromise. In particular, consider the example of a person who's the last within a group to maintain a port/build/distribution on a hard-to-find platform, who then leaves the group - it may be difficult to find someone else to replace them, so new builds may not be available - but software which was once considered working and official shouldn't lose that status because of the change in group membership. Certainly, in the best of all possible worlds, everyone who installs software would have access to online CRL and CA resources, and we wouldn't need to think about whether or not a particular snapshot of reality is misleading in an especially optimistic or pessimistic way - but I believe we should not design (only) for that world. In the absence of semantic information about revocations, I think that expiration is a more appropriate model where no compromise is reasonably suspected, and that revocation is a more appropriate model where compromise is suspected or asserted. -- Greg Broiles [EMAIL PROTECTED] Organized crime is the price we pay for organization. -- Raymond Chandler - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jul 2001, Greg Broiles wrote: At 02:13 PM 7/3/2001 -0400, V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Because current systems don't, to my knowledge, allow the creators of revocations to specify the reason(s) for revocation, I wonder if it would be better to rely on short-lived keys or certs which are renewed frequently during a person's membership or association with a group. They do. GnuPG for example allows the user to choose between three main reasons, then to add a variable length string explaining the revocation. GnuPG output example: Please select the reason for the revocation: 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used 0 = Cancel (Probably you want to select 1 here) Your decision? 3 Enter an optional description; end it with an empty line: To our surprise Alex actually found a girlfriend! He no longer has time to work on this project. - VAB -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQE7QiqH+pIJc5kqSz8RAnJ3AKCpsqwpoB1oHvQv4/oMZJO6T/ZoKwCcCK8a f43nG9WYxKmZC9aaA+HQe4M= =D067 -END PGP SIGNATURE- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Oh? How? All you are suggesting is that the role key is held by a CA - well, who is that going to be, then? Unh, no. The same way the ASF determines who gets commit access could be teh same way the ASF determines who their CA will give release-signing keys to. The same way the ASF takes away someone's commit access is the same way they could update the CRL. All those key update, distribution, revocation, etc., stuff -- all those hard problems you said you want to automate -- go away. Recipients need only trust the Apache CA and its CRL. /r$ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jul 2001, Ben Laurie wrote: What this does not address is the common situation where the distribution gets signed by a different person each time (example: Apache). I had hoped the suggestion to identify a release master was sufficient. Thanks allot for your input. You make very good points, and I'll extend the next version of the HOWTO to cover this content. The obvious answer is use a role key. This doesn't work - how does one control who gets it? How is it distributed? What happens when a developer leaves the group (the role key has to be revoked and we start all over again?)? You have to build a whole organisation around the key, which is unlikely to happen at all, let alone be secure. In the case of small projects the role key could be shared, distributed hand to hand on a floppy or sent through PGP encrypted email. In the case of a large project like Apache, this obviously isn't possible. In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Role keys could be identified by signatures from a Master Key in a traditional model (much like PKI), through the posting of a list of authorized keys digitally signed with a master key, or in an anarchistic model (which it sounds to me is what you're describing) by signatures from other core developers. A threshhold could be established to consider a key officially certified for release, or a single signature could be acceptable. Maybe this is what you're looking for, a model of authorization like PKI except that it is based in the model of PGP's decentralized web of trust? Granted totally decentralized project like Apache cannot adopt the steps of the howto exactly as they are written with out altering their release model. However, such projects can make extremely beneficial use of third party testimonials, as the Apache Project does. Third party signatures on releases could be distributed with the release and the third parties performing those signatures could be the core developers. Core developers are obviously in a strong position to speak about authenticity and content. While the use of core developer signatures as third party testimonials would make such a group slightly more vulnerable to trojan horse attacks via faked key pairs, this level of increased vulnerability is not (in my opinion) very significant. The howto is just a guide. It is meant to be modified by individual projects as they see fit. I don't see the model you're describing as a barrier to adoption of a strong distribution model on the part of the apache project. In fact, the Apache Group seems to be using a strong distribution model for most of it's releases now. I modeled some of the content in the howto after the Apache practices. I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. Also, it would be nice to see the Apache group make its use of PGP signatures more prominent by posting a signature policy (if one is developed), and by linking to keys on a trusted keyserver as well as distributing them from the site so that new signatures are immediately available to people who wish to verify the testimonials of the core developers. Finally, perhaps the Apache Foundation would be willing to pick up the standards put forth in the HOWTO for files names of signatures? Everyone is pretty much doing their own thing right now - I tried to pick up the most popular stuff for standards I put forth in the howto. So, you pretty clearly have to do something that allows multiple keys to be used. It seems to me that the way to do this is to have tools that manage a set of keys which may change over time. The keys sign each other (the signatures would have to be tagged as signatures that allow a particular software distribution to be signed) and the user trusts the _set_ of keys, using the tools to check how keys get added and removed, ensuring that appropriate signatures are on new keys, and that revocations of old keys/signatures are checked. Organisations like the Apache Software Foundation can also have cross-checking between sets of keys to reduce the pain of building initial trust in a set of keys for a new piece of software from that organisation. [...] It is a non-trivial task, so if anyone wants to help with it, please let me know! I've been working on
Re: Crypographically Strong Software Distribution HOWTO
Rich Salz wrote: Oh? How? All you are suggesting is that the role key is held by a CA - well, who is that going to be, then? Unh, no. The same way the ASF determines who gets commit access could be teh same way the ASF determines who their CA will give release-signing keys to. The same way the ASF takes away someone's commit access is the same way they could update the CRL. All those key update, distribution, revocation, etc., stuff -- all those hard problems you said you want to automate -- go away. Recipients need only trust the Apache CA and its CRL. So how does this work in practice? How does an ASF subproject instruct the CA? How does one that's more divorced from any kind of formal structure? Seems to me you are introducing a monster security hole unless you somehow secure the instructions to the CA - and I can't see how to do that at all - at least, not without doing what I already proposed (and having the CA as the sole monitor of the correctness of the process). If Verisign can be spoofed into signing a Microsoft key, what hope for this model? None, IMO. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
What this does not address is the common situation where the distribution gets signed by a different person each time (example: Apache). I've put some pretty serious thought into this problem and come to a few conclusions. The obvious answer is use a role key. All that work... when a conventional PKI will solve all the problems you listed. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Role keys could be identified by signatures from a Master Key in a traditional model (much like PKI), through the posting of a list of authorized keys digitally signed with a master key, or in an anarchistic model (which it sounds to me is what you're describing) by signatures from other core developers. A threshhold could be established to consider a key officially certified for release, or a single signature could be acceptable. Maybe this is what you're looking for, a model of authorization like PKI except that it is based in the model of PGP's decentralized web of trust? I am, but I don't like the idea of core developers - you are merely pushing back the place where you want a single key (or a well-defined set of keys) - and I claim that is not a realistic plan. You have to also allow the set of core developers to gradually change over time. Granted totally decentralized project like Apache cannot adopt the steps of the howto exactly as they are written with out altering their release model. However, such projects can make extremely beneficial use of third party testimonials, as the Apache Project does. Third party signatures on releases could be distributed with the release and the third parties performing those signatures could be the core developers. Core developers are obviously in a strong position to speak about authenticity and content. While the use of core developer signatures as third party testimonials would make such a group slightly more vulnerable to trojan horse attacks via faked key pairs, this level of increased vulnerability is not (in my opinion) very significant. Agreed. I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. I'm not sure I understand the significance of this request - why are version 4 keys better? Also, it would be nice to see the Apache group make its use of PGP signatures more prominent by posting a signature policy (if one is developed), and by linking to keys on a trusted keyserver as well as distributing them from the site so that new signatures are immediately available to people who wish to verify the testimonials of the core developers. Finally, perhaps the Apache Foundation would be willing to pick up the standards put forth in the HOWTO for files names of signatures? Everyone is pretty much doing their own thing right now - I tried to pick up the most popular stuff for standards I put forth in the howto. So, you pretty clearly have to do something that allows multiple keys to be used. It seems to me that the way to do this is to have tools that manage a set of keys which may change over time. The keys sign each other (the signatures would have to be tagged as signatures that allow a particular software distribution to be signed) and the user trusts the _set_ of keys, using the tools to check how keys get added and removed, ensuring that appropriate signatures are on new keys, and that revocations of old keys/signatures are checked. Organisations like the Apache Software Foundation can also have cross-checking between sets of keys to reduce the pain of building initial trust in a set of keys for a new piece of software from that organisation. [...] It is a non-trivial task, so if anyone wants to help with it, please let me know! I've been working on code similar to what you're describing as prototype perl scripts which I intend to port to patches against GnuPG. I'd be happy to help develop the tools necessary to allow Apache to embrace a strong distribution model more easily. Further, I would be greatfull to have an opportunity to contribute to a project such as Apache. Just let me know what you have and what you need. OK, looks like a new project is about to be born. Apache guys: does the ASF want to adopt this (given that the substrate is likely to be GPLed)? Or shall I set it up on my servers? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL
Re: Crypographically Strong Software Distribution HOWTO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Jul 2001, Ben Laurie wrote: I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. I'm not sure I understand the significance of this request - why are version 4 keys better? Let me speak to version 3 PGP keys (version 2 keys are obvious afterwards). Version 3 keys create key fingerprints with MD5 which results in only a 32 byte hash as opposed to the 40 byte fingerprint produced by the use of SHA1 hash in openPGP version 4. In openPGP version 4, the keyid is the low 8 bytes of the SHA1 hash/fingerprint and the full keyid is the low 16 bytes of the hash/fingerprint. In version 3, there is no full keyid (16 byte ID) and the 8 bytes of the keyid are independent of the key fingerprint (It is the low 64bits of the public modulus of the RSA key). The use of MD5, and the failure to hash the full key material to generate the keyid makes version 3 keys significantly weaker (key id and fingerprint collisions, key content modifications) than version 4 keys. (Keep in mind that most PGP programs retrieve PGP keys from the keyservers, and specify keys in program operation, by the 8 byte keyid.) A quote from RFC2440 on Version 3 Keys: V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. So, everyone should generate all new keys with the version 4 format. I think it's a very good idea to attempt to migrate to the version 4 format if at all possible. Many people are still using version 2.6.x of PGP because of its source available status. This is obviously a bad thing. Those people should convert to GnuPG which runs on most platforms (including microsoft windows). Since most projects and developers do not yet have PGP keys and webs of trust set up, it is logical to have them use version 4. The projects which do have developers with version 2 and 3 keys usually don't have webs of trust set up which makes it of little cost to discard and replace the older keys. In the case of a project like Apache where there is an existing web of trust and a number of version 2 and 3 keys, there will be a significant cost to discard the older keys. The cost of the elimination of web of trust links is what I was referring to in the howto by 'good reason not to do so' when I said: I strongly suggest that you revoke any version 2 or version 3 public keys and replace them with version 4 keys unless you have good reason not to do so. However, due to the weaknesses in version 3 keys, it makes sense to attempt to start a migration in the Apache Project and the ASF to the openPGP version 4 format keys. Particularly with a conference coming up where developers will hopefully be able to get together and sign keys. Obviously, there has not been a compromise of the version 2 and version 3 formats that imparts an immediate need to revoke older keys and discard the links in the Apache Web of Trust. But, in my opinion there is still sufficient cause for migration to version 4. Apache members can have both a new version 4 replacement key and a well integrated version 2 or 3 key. Hopefully, the version 4 key will soon be well integrated and the version 2 or 3 key can be revoked. Until that time, a reciprocal signature between the old and new keys of an individual should provide for sufficient trust of new keys. It is just a suggestion. - VAB - --- V. Alex Brennen [EMAIL PROTECTED] [ http://www.cryptnet.net/people/vab/ ] [ http://www.advogato.org/person/vab/ ] C R Y P T O A N A R C H I S T -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQE7QhjX+pIJc5kqSz8RAiIYAKCBZmoTQY0ZsSiQ40WcEeZep9MI/wCeMLvo 1hSHI7Noy3/4lgZOVXzCRwI= =XZ13 -END PGP SIGNATURE- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
On Tue, 3 Jul 2001, Rich Salz wrote: So how does this work in practice? Who controls commit access? What mechanisms protect that? The same mechanisms that protect *the source* can be the same mechanisms that protect *the release.* I believe we have a greater need for protecting the releases with PGP than we have for protecting the source code. (For the releases it's close to the only line of defense; the source code can more easily be taken out of distribution and it's easier to verify). - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 100M impressions per day, http://valueclick.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
On Mon, Jul 02, 2001 at 04:37:00PM -0400, Rich Salz wrote: I've written a HOWTO on the cryptographically strong distribution of computer software. Any constructive criticism would be appreciated. Seems pretty nice; thanks for doing this. Any chance of using SHA1 instead of MD5? MD5 seems to have weaknesses; the IETF says not to use it in their protocols, for example. Any references for either the weaknesses of md5, or what the IETF has to say on the issue? -- Kent Crispin Be good, and you will be [EMAIL PROTECTED] lonesome. -- Mark Twain - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
In our last episode (Re: Crypographically Strong Software Distribution HOWTO, shown on 7/2/01), Kent Crispin said: Any references for either the weaknesses of md5, or what the IETF has to say on the issue? Hans Dobbertin found some weaknesses in MD5 in 1996. I found two quickie references, a note by Dobbertin on the issue: http://www.math.ohio-state.edu/~fiedorow/PGP/MD5_discussion and his paper on the weaknesses: http://www.cs.ucsd.edu/users/bsy/dobbertin.ps The short answer is that he found weaknesses in MD5 similar to the weaknesses found in MD4 before it was broken. The message since then has been don't panic, but use a newer algorithm for new work. (In fact, the Dobbertin note above says not to panic, but start looking for better algorithms.) The answer is that you SHOULD (in IETF terms, see RFC 2119, http://www.ietf.org/rfc/rfc2119.txt for a definition of MAY, SHOULD, MUST, etc.) use SHA-1. In plain language, what this means is that if you don't know when to use MD5 and when to use SHA1, then use SHA1. If you pick MD5, be prepared to answer people when they ask why you did. If for some reason you don't want to use SHA1, look at RIPE-MD160. If you don't like either of them, there are other choices, but we now start getting into subtlety and taste. On the other hand, in the intervening five years, we haven't seen a break in MD5 appear. So maybe it's not as bad as we thought. Nonetheless, if you have a choice and you don't know what to do, pick SHA1. At the very least, no one will send you an email that starts, Why did you use MD5? Don't you know that Hans Dobbertin Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
On Mon, 2 Jul 2001, Jon Callas wrote: The answer is that you SHOULD (in IETF terms, see RFC 2119, http://www.ietf.org/rfc/rfc2119.txt for a definition of MAY, SHOULD, MUST, etc.) That document clarifies nothing, it might as well say the following - 1. MUST This word, or the terms REQUIRED or SHALL, mean that the anyone violating the definition is a BAD PERSON. 3. SHOULD This word, or the adjective RECOMMENDED, mean that anyone violating the definition might or might not be a BAD PERSON. On the other hand, in the intervening five years, we haven't seen a break in MD5 appear. So maybe it's not as bad as we thought. Nonetheless, if you have a choice and you don't know what to do, pick SHA1. At the very least, no one will send you an email that starts, Why did you use MD5? Don't you know that Hans Dobbertin Most applications which move around files identify them by sha1 hash, so if you use sha1 you might be able to use interoperability at some point. With md5 that isn't a possibility. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Jon Callas wrote: Hans Dobbertin found some weaknesses in MD5 in 1996. I found two quickie references, a note by Dobbertin on the issue: http://www.math.ohio-state.edu/~fiedorow/PGP/MD5_discussion and his paper on the weaknesses: http://www.cs.ucsd.edu/users/bsy/dobbertin.ps The short answer is that he found weaknesses in MD5 similar to the weaknesses found in MD4 before it was broken. ... Also note that RFC 2104 on the HMAC construction used in IPSEC explicitly cites Dobbertin and says the attack does not apply: ... MD5 has been recently shown to be vulnerable to collision search attacks [Dobb]. This attack and other currently known weaknesses of MD5 do not compromise the use of MD5 within HMAC as specified in this document - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
I've written a HOWTO on the cryptographically strong distribution of computer software. Any constructive criticism would be appreciated. I hope to standardize the use of this model in the GNU/Linux free software community. You can find the HOWTO here: http://www.cryptnet.net/fdp/crypto/strong_distro.html Thanks, - VAB I have another quibble with what is a really good start on a HOWTO. You say in your section on anonymous software development groups, The identity of the maintainer is established through the possession of the secret key of a project key pair, therefore possession of the secret key could be presented as proof in a courtroom as evidence that an individual is a maintainer or developer in a Guerrilla development project. This evidence would be very difficult to refute in court. The only possible argument that could be used to deny authorship would be to state the the secret key was stolen. However, typeo === that the theft of a secret key suggest other felony crimes where committed. To a lesser extent, possession of the revocation certificate has similar ramifications. If the secret key and/or revocation certificate was widely distributed, say by being posted to the cypherpunks mailing list, it seems unlikely that mere possession would constitute strong proof of membership in the development group. If the key becomes widely distributed, the development group must immediately take steps to establish the reputation of a new key. There might be an interesting scramble between the development group, and other group(s) wishing to obtain the reputation of the development group. Cheers - Bill - Bill Frantz | The principle effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Hans Dobbertin found some weaknesses in MD5 in 1996. Also note that RFC 2104 on the HMAC construction used in IPSEC explicitly cites Dobbertin and says the attack does not apply: this is because dobbertin's attack works only against message-digest applications of md5; his attack doesn't work against md5 MACs, ie, when md5 is used to hash a symmetric key with the plaintext. but, i generally tell clients to use sha-1 even for MACs, just to avoid confusing their customers. - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
