Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Eric Rescorla e...@networkresonance.com writes: At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote: Steven M. Bellovin s...@cs.columbia.edu writes: So -- who supports TLS 1.2? Not a lot, I think. The problem with 1.2 is that it introduces a pile of totally gratuitous incompatible changes to the protocol that require quite a bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not a bigger step, than the change from SSL to TLS), complicate an implementation, are difficult to test because of the general lack of implementations supporting it, and provide no visible benefit. Why would anyone rush to implement this when what we've got now works[0] just fine? Ordinarily I wouldn't bother to respond to Peter's curmudgeon act, :-). but since I was obviously heavily involved with TLS 1.2, I think a bit of context is in order. I'm aware of why the changes were made, but the point of my comment was to explain their consequences in the lack of support for TLS 1.2. I had (AFAIK) one of the first implementations of TLS 1.1, an incremental upgrade of TLS 1.0 (and then had some fun trying to find things to interop against) but for TLS 1.2 I haven't implemented it and have no plans to implement it because it provides absolutely no benefit over TLS 1.1 and a great many downsides. Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those between SSL and TLS. I'm not particularly happy about that either, but it's what we felt was necessary to do a principled job. It may have been a nicely principled job but what actual problem is the switch in hash algorithms actually solving? Making changes of such magnitude to a very, very widely-deployed protocol is always a tradeoff between the necessity of the change and the pain of doing so. In TLS 1.2 the pain is proportionate to the scale of the existing deployed base (i.e. very large) and the necessity of doing so appears to be zero. I don't know of any attack or threat to the existing dual-hash mechanism that TLS 1.2 addresses, and it may even make things worse by switching from the redundant dual-hash (a testament to the original SSL designers) to a single algorithm. This is why I called the changes gratuitous, there is no threat that they address - it can even be argued (no doubt endlessly) that they make the PRF weaker rather than stronger - but they come at considerable cost. SSL/TLS is (and has been for many years) part of the Internet infrastructure. You don't make significant, totally incompatible changes to the infrastructure without very carefully weighing the advantages and disadvantages. Maybe there'll be a sudden flood of unexpected TLS 1.2 implementations right after I post this, but at the moment it seems that implementors have weighed up the cost and said no thanks. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Sat, Jan 24, 2009 at 2:36 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: You seem to be out of touch I am afraid. Just look at what many O/S distributions do. They adopt a new OpenSSL 0.9.Xy release from time to time (for some initial y) and back-port security fixes never changing the letter. One can't actually tell from openssl version what version one is running and which fixes have been applied. Why am I back-porting patch-sets to 0.9.8i? Is that because there is no demand for bugfix releases? There is indeed demand for real bugfix releases, just that people have gotten used to doing it themselves, but this is not very effective and is difficult to audit. It is not that I am unaware of this, I was pointing out what we actually do. But you do have a fair point and I will take it up with the team. However, I wonder how this is going to pan out? Since historically pretty much every release has been prompted by a security issue, but also includes new features and non-security bugfixes, in order to release 0.9.8j the way you want us to, we would also have to test and release security updates for 0.9.8 - 0.9.8i, for a total of 10 branched versions. I think this is asking rather a lot of volunteers! Don't suggest that we should release feature/bugfix versions less often, I think we already do that less often than we should. Perhaps the answer is that we security patch every version that is less than n months old, and end-of-life anything before that? Suggestions for reasonable values of n? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
At Sat, 24 Jan 2009 14:55:15 +1300, Peter Gutmann wrote: Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those between SSL and TLS. I'm not particularly happy about that either, but it's what we felt was necessary to do a principled job. It may have been a nicely principled job but what actual problem is the switch in hash algorithms actually solving? Making changes of such magnitude to a very, very widely-deployed protocol is always a tradeoff between the necessity of the change and the pain of doing so. In TLS 1.2 the pain is proportionate to the scale of the existing deployed base (i.e. very large) and the necessity of doing so appears to be zero. I don't know of any attack or threat to the existing dual-hash mechanism that TLS 1.2 addresses, and it may even make things worse by switching from the redundant dual-hash (a testament to the original SSL designers) to a single algorithm. This is why I called the changes gratuitous, there is no threat that they address - it can even be argued (no doubt endlessly) that they make the PRF weaker rather than stronger - but they come at considerable cost. I agree that given the current set of attacks on SHA-1 and MD5, there was no existing attack on the protocol. However, that doesn't mean that improvements in analysis wouldn't lead to such attacks and so the general feeling of the community was to err on the side of safety. No doubt if we hadn't done so, there would be people screaming about how TLS still used MD5. Indeed, that's how this thread started. So, once again, I don't share your opinions about these changes being gratuitous. Moreover, the bulk of the changes weren't to the PRF. That's actually quite a trivial change to implement, but rather to have accurate signalling about what combinations of hashes and signatures implementations could support--something that was painfully non-orthogonal in SSLv3 and earlier versions of TLS. Again, one could argue that we could have hacked around this and indeed the original Bellovin-Rescorla paper described a number of such hacks, but the general feeling of the TLS WG was that it was more important to get it right. SSL/TLS is (and has been for many years) part of the Internet infrastructure. You don't make significant, totally incompatible changes to the infrastructure without very carefully weighing the advantages and disadvantages. Which we did--including having the very discussion we are having now--and concluded that the course of action we took was the right one. You're of course free to weigh the evidence yourself and come to a different conclusion, and even to hold the opinion that those who agree with you are complete fools, but it's simply not accurate to imply, as you do here, that we didn't think about it. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Tue, Jan 20, 2009 at 5:14 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote: The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) It would be helpful if as a first step, SSL_library_init() (a.k.a. OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests, I would make this change in the 0.9.9 development snapshots. [ Off topic: I find OpenSSL release-engineering a rather puzzling process. The patch releases are in fact feature releases, Who said they were patch releases? and there are no real patch releases even for critical security issues. I chose to backport the 0.9.8j security fixes to 0.9.8i and sit out all the new FIPS code, ... This should not be necessary. I really hope to see real OpenSSL patch releases some day with development of new features *strictly* in the development snapshots. Ideally this will start with 0.9.9a, with no new features, just bugfixes, in [b-z]. ] I think that is not likely to happen, because that's not the way it works. The promise we try to keep is ABI compatibility between releases that have the same numbers. Letters signify new versions within that series. We do not have a bugfix-only branch. There doesn't seem to be much demand for one. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Fri, Jan 23, 2009 at 04:01:50PM +1100, Ben Laurie wrote: I really hope to see real OpenSSL patch releases some day with development of new features *strictly* in the development snapshots. Ideally this will start with 0.9.9a, with no new features, just bug-fixes, in [b-z]. ] I think that is not likely to happen, because that's not the way it works. The promise we try to keep is ABI compatibility between releases that have the same numbers. Letters signify new versions within that series. We do not have a bugfix-only branch. There doesn't seem to be much demand for one. Don't want to start a long debate here, but I do want to respond to this. You seem to be out of touch I am afraid. Just look at what many O/S distributions do. They adopt a new OpenSSL 0.9.Xy release from time to time (for some initial y) and back-port security fixes never changing the letter. One can't actually tell from openssl version what version one is running and which fixes have been applied. Why am I back-porting patch-sets to 0.9.8i? Is that because there is no demand for bugfix releases? There is indeed demand for real bugfix releases, just that people have gotten used to doing it themselves, but this is not very effective and is difficult to audit. OpenSSL has not infrequent security advisories, and these are always fixed in new feature releases not bugfix releases (which are misleadingly called patch releases). #define HEADER_OPENSSLV_H /* Numeric release version identifier: * MNNFFPPS: major minor fix patch status * The status nibble has one of the values 0 for development, 1 to e for betas * 1 to 14, and f for release. The patch level is exactly that. * For example: * 0.9.3-dev 0x00903000 * 0.9.3-beta10x00903001 * 0.9.3-beta2-dev 0x00903002 * 0.9.3-beta20x00903002 (same as ...beta2-dev) * 0.9.3 0x0090300f * 0.9.3a 0x0090301f * 0.9.4 0x0090400f * 1.2.3z 0x102031af * * For continuity reasons (because 0.9.5 is already out, and is coded * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level * part is slightly different, by setting the highest bit. This means * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start * with 0x0090600S... * * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.) * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for * major minor fix final patch/beta) */ #define OPENSSL_VERSION_NUMBER 0x0090809fL -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote: Steven M. Bellovin s...@cs.columbia.edu writes: So -- who supports TLS 1.2? Not a lot, I think. The problem with 1.2 is that it introduces a pile of totally gratuitous incompatible changes to the protocol that require quite a bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not a bigger step, than the change from SSL to TLS), complicate an implementation, are difficult to test because of the general lack of implementations supporting it, and provide no visible benefit. Why would anyone rush to implement this when what we've got now works[0] just fine? Ordinarily I wouldn't bother to respond to Peter's curmudgeon act, but since I was obviously heavily involved with TLS 1.2, I think a bit of context is in order. Nearly all the changes to TLS between 1.1 and 1.2 were specifically designed to accomodate new digest algorithms throughout the protocol. For those of you who aren't TLS experts, TLS had MD5 and SHA-1 wired all throughout the protocol and we had to arrange to strip them out, plus find a way to signal that you were willing to support the newer algorithms. To avoid this becoming a huge pile of hacks, we had to restructure some of the less orthogonal negotiation mechanisms. The other major (and totally optional) change was the addition of combined cipher modes like GCM. That change was made primarily because we were in there and there was some demand for those modes. So, no, I don't consider these changes gratuitous, though of course they are incompatible. Yes, there were simpler things we could have done, such as just specifying a new set of fixed digest algorithms to replace MD5 and SHA-1, but I and others felt that this was unwise from a futureproofing perspective. Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those between SSL and TLS. I'm not particularly happy about that either, but it's what we felt was necessary to do a principled job. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Jon Callas j...@callas.org writes: I've always been pleased with your answer to Question J, so I'll say what we're doing at PGP. That wasn't really meant as a compliment :-). The problem is that by leaping on things the instant they appear you end up having to support a menagerie of wierdo algorithms and mechanisms that the industry as a whole never adopts. How many crypto libraries that could be used to implement the OpenPGP spec actually support Haval, or Tiger, or Twofish, or SAFER-SK128? The result of this too-quick adoption has been a bunch of gaps in newer versions of the spec (look for a range of algorithm IDs marked as reserved) where algorithms adopted too quickly were removed again when they failed to gain general (or any) acceptance. Another concern with too-quick adoption is the potential for moving to an algorithm that's later found to be flawed. This hasn't happened yet for cryptographer-designed algorithms and mechanisms (as opposed to WEP et al) but it's quite possible that some new algorithm introduced at Crypto n is shown to reduce to rot-13 in a paper published in Crypto n+1. I use an informal five- year rule that I won't make an algorithm a default (i.e. enabled without explicit user action) until it's had active attention paid to it for at least five years, where active attention means not so much published in an obscure conference somewhere but required in an industry spec or something similar that results in active scrutiny of its security. (Actually it's not quite that simple, it's more of a balancing act and the pace depends on whether there are credible threats to the current default algorithm or not). In crypto, new doesn't necessarily mean better, it can also mean riskier. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin s...@cs.columbia.edu wrote: I've mentioned it before, but I'll point to the paper Eric Rescorla wrote a few years ago: http://www.cs.columbia.edu/~smb/papers/new-hash.ps or http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: if you're running a public-facing web server, you *can't* offer a SHA-2 certificate because you have no way of knowing if the client supports SHA-2. Fixing that requires a TLS fix; see the above timeline for that. The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) Bodo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Paul Hoffman wrote: At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote: When in 2012 the winner of the NIST SHA-3 competition will be known, and everybody will start using it (so that according to Peter's estimates, by 2018 half of the implementations actually uses it), do we then have enough redundancy? No offense, Benne, but are serious? Why would everybody even consider it? Give what we know about the design of SHA-2 (too little), how would we know whether SHA-3 is any better than SHA-2 for applications such as digital certificates? In specific, if most systems have implemented the whole SHA-2 family by the time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would argue that it is probably much more prudent to change to SHA-2/384 than to SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will have had significantly more study. Can you state the assumptions for why you think that moving to SHA384 would be safe if SHA256 was considered vulnerable in some way please. SHA256,384,512 are a suite all built on the same basic algorithm construction. Depending on how SHA256 fell the whole suite could be vulnerable irrespective of the digest length or maybe it won't be. Until we know how the SHA3 digest is actually constructed the same could even be true of that. I don't think it depends at all on who you trust but on what algorithms are available in the protocols you need to use to run your business or use the apps important to you for some other reason. It also very much depends on why the app uses the crypto algorithm in question, and in the case of digest/hash algorithms wither they are key'd (HMAC) or not. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
At 1:38 PM + 1/19/09, Darren J Moffat wrote: Can you state the assumptions for why you think that moving to SHA384 would be safe if SHA256 was considered vulnerable in some way please. Sure. I need 128 bits of pre-image protection for, say, a digital signature. SHA2/256 is giving me that. Then, due to some weakness, it is only giving me 112 bits of protection. The weakness is understood in the crypto community, and it's a straight-line loss of bits of protection. SHA2/384 would then give me 168 bits of protection, which is more than the 128 what I need. Even if you don't trust that there is a straight-line loss of bits, you would have to be believing that the attack is much worse for SHA2/384 than it was for SHA2/256 in order to bring the output down to the level that I need. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote: The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) It would be helpful if as a first step, SSL_library_init() (a.k.a. OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests, I would make this change in the 0.9.9 development snapshots. [ Off topic: I find OpenSSL release-engineering a rather puzzling process. The patch releases are in fact feature releases, and there are no real patch releases even for critical security issues. I chose to backport the 0.9.8j security fixes to 0.9.8i and sit out all the new FIPS code, ... This should not be necessary. I really hope to see real OpenSSL patch releases some day with development of new features *strictly* in the development snapshots. Ideally this will start with 0.9.9a, with no new features, just bugfixes, in [b-z]. ] -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Mon, 19 Jan 2009 10:45:55 +0100 Bodo Moeller bmoel...@acm.org wrote: On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin s...@cs.columbia.edu wrote: I've mentioned it before, but I'll point to the paper Eric Rescorla wrote a few years ago: http://www.cs.columbia.edu/~smb/papers/new-hash.ps or http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: if you're running a public-facing web server, you *can't* offer a SHA-2 certificate because you have no way of knowing if the client supports SHA-2. Fixing that requires a TLS fix; see the above timeline for that. The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) So -- who supports TLS 1.2? (Btw -- note the date of that RFC: August 2008. That's almost exactly 3 years after ekr and I published our paper. Since ekr is co-chair of the TLS working group, we can assume that that group was aware of the problem. See what Peter and I said about how long it takes to get any changes deployed.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Steven M. Bellovin s...@cs.columbia.edu writes: So -- who supports TLS 1.2? Not a lot, I think. The problem with 1.2 is that it introduces a pile of totally gratuitous incompatible changes to the protocol that require quite a bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not a bigger step, than the change from SSL to TLS), complicate an implementation, are difficult to test because of the general lack of implementations supporting it, and provide no visible benefit. Why would anyone rush to implement this when what we've got now works[0] just fine? Peter. [0] For whatever level of works applies to SSL/TLS, in the sense that 1.2 won't work any better than 1.1 does. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
I have a general outline of a timeline for adoption of new crypto mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt , see Question J about 2/3 of the way down. It's not meant to be definitively accurate for all cases but was created as a rough guideline for people proposing to introduce new crypto mechanisms to give an idea of how long they should expect to wait to see them adopted. I've always been pleased with your answer to Question J, so I'll say what we're doing at PGP. We deprecated MD5 in '97. That was one of the main points of the new formats that became OpenPGP was that agility has its own challenges, but it's worth it. We had a meeting recently to look at what we're going to do. Our first thoughts were that we would scrub MD5 from the UI and be done with it. Then we realized that we need to leave enough of the old UI so that people can *remove* MD5 from their use. We decided that we'll issue warnings in the annotations when we verify MD5 signatures. We can't stop verifying them, but we'll do an equivalent to what we do with 40-bit crypto in S/MIME. (40-bit still harries S/MIME; it's really a pity that we have to deal with it. Our solution is that 40-bit crypto is just a fancy form of plaintext. We decode it the way we decode quoted-printable, base64, and other fancy forms of plaintext.) We debated removing it from the APIs, and concluded that that is asking for trouble, because someone will need to do that for diagnostic and testing purposes. We've started deprecating the 160-bit hashes. There will be comments in the UI for both SHA-1 and RIPE-MD/160. We think NIST's advice for phasing them out next year is just fine, and so we'll start really phasing them out next year. Lastly, we considered other options for hash algorithms. Presently, it's too early to do anything, but we'll look at it again when we do more work on the 160-bit hashes. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Mon, Jan 19, 2009 at 01:38:02PM +, Darren J Moffat wrote: I don't think it depends at all on who you trust but on what algorithms are available in the protocols you need to use to run your business or use the apps important to you for some other reason. It also very much depends on why the app uses the crypto algorithm in question, and in the case of digest/hash algorithms wither they are key'd (HMAC) or not. As Jeff Hutzelman suggested recently, inspired by the SSHv2 CBC mode vulnerability, hash algorithm agility for PKI really means having more than one signature, each using a different hash, in each certificate; this enlarges certificates. Alternatively, it needs to be possible to select what certificate to present to a peer based on an algorithm negotiation; this tends to mean adding round-trips to our protocols. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Weger, B.M.M. de b.m.m.d.we...@tue.nl writes: Bottom line, anyone fielding a SHA-2 cert today is not going=20 to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? I have a general outline of a timeline for adoption of new crypto mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see Question J about 2/3 of the way down. It's not meant to be definitively accurate for all cases but was created as a rough guideline for people proposing to introduce new crypto mechanisms to give an idea of how long they should expect to wait to see them adopted. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Weger, B.M.M. de wrote: In my view, the main lesson that the information security community, and in particular its intersection with the application building community, has to learn from the recent MD5 and SHA-1 history, is that strategies for dealing with broken crypto need rethinking. On the other hand, compared to many other aspects of our security infrastructure, even MD5 does quite well. Of course, that is not meant to be taken as an excuse. I agree with your call to have smooth transition systems to go from one cipher to another, but when to make the transition is a difficult decision to make. PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) offering the video and audio files of the 25c3 presentation MD5 considered harmful today, provide for integrity checking of those files their, uhm, MD5 hashes. It seems to me they are only provided to protect against transmission errors, and they are fine for that. Otherwise, it would be a more serious mistake to transfer them in-band. Security is a spectrum. Thanks, Marcus - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Mon, 12 Jan 2009 16:05:08 +1300 pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote: Weger, B.M.M. de b.m.m.d.we...@tue.nl writes: Bottom line, anyone fielding a SHA-2 cert today is not going=20 to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? I have a general outline of a timeline for adoption of new crypto mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see Question J about 2/3 of the way down. It's not meant to be definitively accurate for all cases but was created as a rough guideline for people proposing to introduce new crypto mechanisms to give an idea of how long they should expect to wait to see them adopted. My analysis is similar to Peter's: 2-3 years for an RFC, 2-3 years for design/code/test, 2 years average delay for the next major release of Windows which will include it, 5 years for most of the older machines to die off. I've mentioned it before, but I'll point to the paper Eric Rescorla wrote a few years ago: http://www.cs.columbia.edu/~smb/papers/new-hash.ps or http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: if you're running a public-facing web server, you *can't* offer a SHA-2 certificate because you have no way of knowing if the client supports SHA-2. Fixing that requires a TLS fix; see the above timeline for that. -- --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Hi Victor, Bottom line, anyone fielding a SHA-2 cert today is not going to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? The first weakness shown in MD5 was not in 2004 but in 1995. Apparently it takes a very long time before the awareness about the implications of using weakened or broken crypto has reached a sufficient level. Though I understand the practical issues you're talking about, Victor, my bottom line is different. In my view, the main lesson that the information security community, and in particular its intersection with the application building community, has to learn from the recent MD5 and SHA-1 history, is that strategies for dealing with broken crypto need rethinking. [[Maybe in the previous sentence the word intersection should be replaced by union.]] Grtz, Benne de Weger PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) offering the video and audio files of the 25c3 presentation MD5 considered harmful today, provide for integrity checking of those files their, uhm, MD5 hashes. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Sat, Jan 10, 2009 at 11:32:44PM +0100, Weger, B.M.M. de wrote: Hi Victor, Bottom line, anyone fielding a SHA-2 cert today is not going to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? Extremely unlikely in the case of SSL/TLS and X.509 certs. There is a huge install-base of systems on which SHA-2 certs will failed SSL handshakes. When Windows XP systems are 1% of the install-base, when OpenSSL 0.9.8 is 1% of the install-base and 0.9.9 too (if the support is not added before it goes official), and all the browsers, Java libraries, ... support SHA-2, then you can deploy SHA-2 certs. I would estimate 5-8 years, if developers of all relevant mainstream implementations start to address the issue now. SHA-1 will be with us well after 2010. New applications written in 2010 will ideally support SHA-2, but SHA-1 will probably still be the default digest in many applications through 2013 or 2015. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Thu, Jan 08, 2009 at 06:23:47PM -0600, Dustin D. Trammell wrote: Nearly everything I've seen regarding the proposed solutions to this attack have involved migration to SHA-1. SHA-1 is scheduled to be decertified by NIST in 2010, and NIST has already recommended[1] moving away from SHA-1 to SHA-2 (256, 512, etc.). Collision attacks have already been demonstrated[2] against SHA-1 back in 2005, and if history tells us anything then things will only get worse for SHA-1 from here. By not moving directly to at least SHA-2 (until the winner of the NIST hash competition is known), these vendors are likely setting themselves up for similar attacks in the (relatively) near future. All fine and good, but no existing OpenSSL release (including 0.9.9-dev) will by default inter-operate with the resulting (SHA2) certificates. The SSL_library_init() call only initializes ssl ciphers and digests, which do not include SHA-2. So most SSL applications won't be able to verify the certificate signatures. One needs to call OpenSSL_add_all_algorithms() before SHA-2 signed certificates work. Bottom line, anyone fielding a SHA-2 cert today is not going to be happy with their costly pile of bits. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
