Re: Security team successfully cracks SSL using 200 PS3's and MD5
* Joe Greco: A CA statement that they won't issue MD5-signed certificates in the future should be sufficient. There's no need to reissue old certificates, unless the CA thinks other customers have attacked it. That would seem to be at odds with what the people who documented this problem believe. What do they believe? That the CA should reissue certificates even if the CA assumes that there haven't been other attacks? Or that the CA should not reissue, despite evidence of other attacks?
Re: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly
On 03/01/09 07:31, Martin Hannigan wrote: Overall, geo location has turned out to be a somewhat valuable tool in terms of language, fraud, and localization. I think that it's important to continue to urge improvements in this technology, not divestment. Is it really that difficult to check the Accept-Language header for determining the language to use? This is particularly useful in countries that either have no official language, countries that have more than one official language, and tourists.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
Dragos Ruiu wrote: On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: Joe Greco wrote: [ ] Either we take the potential for transparent MitM attacks seriously, or we do not. I'm sure the NSA would prefer not. :-) As for the points raised in your message, yes, there are additional problems with clients that have not taken this seriously. It is, however, one thing to have locks on your door that you do not lock, and another thing entirely not to have locks (and therefore completely lack the ability to lock). I hope that there is some serious thought going on in the browser groups about this sort of issue. [ ... ] ... JG F Y I, see: SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' certificates @ http://www.codefromthe70s.org/sslblacklist.aspx Best. Snort rule to detect said... url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html alert tcp $EXTERNAL_NET $HTTP_PORTS - $HOME_NET any (msg:POLICY Weak SSL OSCP response -- MD5 usage; content:content-type: application/ocsp-response; content:2A 86 48 86 F7 0D 01 01 05; metadata: policy security-ips drop, service http; reference: url, www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; sid:101;) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
Would using the combination of both MD5 and SHA-1 raise the computational bar enough for now, or are there other good prospects for a harder to crack hash? On Sat, Jan 3, 2009 at 9:35 AM, William Warren hescomins...@emmanuelcomputerconsulting.com wrote: Dragos Ruiu wrote: On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: Joe Greco wrote: [ ] Either we take the potential for transparent MitM attacks seriously, or we do not. I'm sure the NSA would prefer not. :-) As for the points raised in your message, yes, there are additional problems with clients that have not taken this seriously. It is, however, one thing to have locks on your door that you do not lock, and another thing entirely not to have locks (and therefore completely lack the ability to lock). I hope that there is some serious thought going on in the browser groups about this sort of issue. [ ... ] ... JG F Y I, see: SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' certificates @ http://www.codefromthe70s.org/sslblacklist.aspx Best. Snort rule to detect said... url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html alert tcp $EXTERNAL_NET $HTTP_PORTS - $HOME_NET any (msg:POLICY Weak SSL OSCP response -- MD5 usage; content:content-type: application/ocsp-response; content:2A 86 48 86 F7 0D 01 01 05; metadata: policy security-ips drop, service http; reference: url, www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; sid:101;) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Jan 3, 2009, at 9:38 AM, Dorn Hetzel wrote: Would using the combination of both MD5 and SHA-1 raise the computational bar enough for now, I have never seen this recommended (and I do try and follow this). or are there other good prospects for a harder to crack hash? The Federal Information Processing Standard 180-2, Secure Hash Standard, specifies algorithms for computing five cryptographic hash functions — SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. SHA-256 is thought to be still safe, unlike SHA-1 http://eprint.iacr.org/2008/271 http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html and its use is recommended by RFC4509. http://tools.ietf.org/html/rfc4509 So, I would use SHA-256 if possible. (SHA-224 is a truncation of -256 - see rfc3874.) There is, BTW, a competition to find a replacement. http://csrc.nist.gov/groups/ST/hash/sha-3/index.html Regards Marshall On Sat, Jan 3, 2009 at 9:35 AM, William Warren hescomins...@emmanuelcomputerconsulting.com wrote: Dragos Ruiu wrote: On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: Joe Greco wrote: [ ] Either we take the potential for transparent MitM attacks seriously, or we do not. I'm sure the NSA would prefer not. :-) As for the points raised in your message, yes, there are additional problems with clients that have not taken this seriously. It is, however, one thing to have locks on your door that you do not lock, and another thing entirely not to have locks (and therefore completely lack the ability to lock). I hope that there is some serious thought going on in the browser groups about this sort of issue. [ ... ] ... JG F Y I, see: SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' certificates @ http://www.codefromthe70s.org/sslblacklist.aspx Best. Snort rule to detect said... url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html alert tcp $EXTERNAL_NET $HTTP_PORTS - $HOME_NET any (msg:POLICY Weak SSL OSCP response -- MD5 usage; content:content-type: application/ocsp-response; content:2A 86 48 86 F7 0D 01 01 05; metadata: policy security-ips drop, service http; reference: url, www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; sid:101;) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
* Brian Keefer: My apologies if you were commenting on some other aspect, or if my understand is in some way flawed. I don't think so. There's a rule of thumb which is easy to remembe: Never revoke anything just because some weak algorithm is involved. The rationale is that that revocation is absolute and (usually) retroactive, but we generally want a more nuanced approach. If certain algorithms are too weak to be used, this is up to the relying party to decide whether it's fine in a particular case. On the other hand, replacing MD5-signed certificates in the browser PKI is costly, but the overhead is very finely dispersed (assuming that reissuing certificates has very little overhead at the CA). I think it's doable if the browser vendors could agree on a flag date after which MD5 signatures on certificates are no longer considered valid. (The implicit assumptions in that rule of thumb do not always apply. For instance, if weak RSA keys are discovered which occur with sufficiently high probability as the result of the standard key generating algorithms to pose a real problem, the public key may not reveal this property immediately, it may only be evident from the private key, or only after a rather expensive computation. In the latter case, we would be in very deep trouble.)
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Sat, 03 Jan 2009 09:35:06 -0500 William Warren hescomins...@emmanuelcomputerconsulting.com wrote: Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense. (a) SHA-1 was not broken as badly. The best attack is, as I recall, 2^63, which is computationally infeasible without special-purpose hardware. (b) Per a paper Eric Rescorla and I wrote, there's no usable alternative, since too many protocols (including TLS) don't negotiate hash functions before presenting certificates. In particular, this means that a web site can't use SHA-256 because (1) most clients won't support it; and (2) it can't tell which ones do. (Note that this argument applies just as much to combinations of hash functions -- anything that *the large majority of today's* browsers don't implement isn't usable.) These two points lead us to (c): security is a matter of economics, not algorithms. Switching now to something else loses more in connectivity or customers than you would lose from such an expensive attack. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files.
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
On Fri, 2 Jan 2009, Mikael Abrahamsson wrote: MD5 is broken, don't use it for anything important. You mean like for BGP neighbors? Wanna suggest an alternative? :-) -Hank
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
Hank Nussbacher wrote: On Fri, 2 Jan 2009, Mikael Abrahamsson wrote: MD5 is broken, don't use it for anything important. You mean like for BGP neighbors? Wanna suggest an alternative? :-) MD5 on BGP sessions has already been proven to not being that effective anyhow, for the purpose that it was intended for. I don't think these findings will make any difference there. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Re: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly
On Sat, Jan 3, 2009 at 6:44 AM, Chris Hills c...@chaz6.com wrote: On 03/01/09 07:31, Martin Hannigan wrote: Overall, geo location has turned out to be a somewhat valuable tool in terms of language, fraud, and localization. I think that it's important to continue to urge improvements in this technology, not divestment. Is it really that difficult to check the Accept-Language header for determining the language to use? This is particularly useful in countries that either have no official language, countries that have more than one official language, and tourists. What's the accuracy rate? Combined, it is probably higher for that specific use case. I digress, ask your favorite search engine. Perhaps they'll explain. It is certainly interesting. [I think that] Over the last year we're seeing an uptick in geo-location problems addressed on NANOG because it's becoming profitable (whether through ads or fraud correlation through ip reputation) and it's probably not going away. Personally, I'd be happier with the publicly available checker. *shrug* YMMV and Best, -M -- Martin Hannigan mar...@theicelandguy.com p: +16178216079
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Sat, Jan 3, 2009 at 10:49 AM, Steven M. Bellovin s...@cs.columbia.edu wrote: On Sat, 03 Jan 2009 09:35:06 -0500 William Warren hescomins...@emmanuelcomputerconsulting.com wrote: Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense. (a) SHA-1 was not broken as badly. The best attack is, as I recall, 2^63, which is computationally infeasible without special-purpose hardware. special purpose? or lots of commodity? like the Amazon-EC2 example used in the cert issue? (or PS3s or...) (b) Per a paper Eric Rescorla and I wrote, there's no usable alternative, since too many protocols (including TLS) don't negotiate hash functions before presenting certificates. In particular, this means that a web site can't use SHA-256 because (1) most clients won't support it; and (2) it can't tell which ones do. (Note that this argument applies just as much to combinations of hash functions -- anything that *the large majority of today's* browsers don't implement isn't usable.) This is a function of an upgrade (firefox3.5 coming 'soon!') for browsers, and for OS's as well, yes? So, given a future flag-day (18 months from today no more MD5, only SHA-232323 will be used!!) browsers for the majority of the market could be upgraded. Certainly there are non-browsers out there (eudora, openssl, wget, curl..bittorrent-clients, embedded things) which either will lag more or break all together. These two points lead us to (c): security is a matter of economics, not algorithms. Switching now to something else loses more in connectivity or customers than you would lose from such an expensive attack. only if not staged out with enough time to roll updates in first, right? -Chris
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
On Sat, 3 Jan 2009, Hank Nussbacher wrote: You mean like for BGP neighbors? Wanna suggest an alternative? :-) Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all. But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
For me the MD5 hashes on file downloads are more valuable to ensure the package is accurate to a byte rather than to verify its authenticity or integrity. Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost complete confidence that the file is the original one? I don't think anyone has been able to create a duplicate file that generates the same SHA-1 *and* MD5 hashes as the original file. Frank -Original Message- From: Florian Weimer [mailto:f...@deneb.enyo.de] Sent: Saturday, January 03, 2009 10:23 AM To: Skywing Cc: NANOG Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files.
RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
What's the cost to switching to something other than MD5 here, though? I agree that users not checking download links is likely more probablistic. But as checking the sums is already entirely a manual process, what's the trouble with switching to sha256 now abd stating this in the DSA mails? No, there probably won't be another major md5 break in six months. Or maybe a year, or two, or... However, the both of us well know that the attacks here won't do anything but get better. Even if it's not a thing to sound a fire drill about, I have to admit that hearing that Debian's going to continue moving forward with md5 until an unspecified somewhen date in the future is a bit disappointing. Not (yet) the end of the world, but I would like to understand the reason (cost) for the pushback here. – S -Original Message- From: Florian Weimer f...@deneb.enyo.de Sent: Saturday, January 03, 2009 08:23 To: Skywing skyw...@valhallalegends.com Cc: Steven M. Bellovin s...@cs.columbia.edu; NANOG nanog@nanog.org Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Sat, 3 Jan 2009 12:31:53 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 3, 2009 at 10:49 AM, Steven M. Bellovin s...@cs.columbia.edu wrote: On Sat, 03 Jan 2009 09:35:06 -0500 William Warren hescomins...@emmanuelcomputerconsulting.com wrote: Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense. (a) SHA-1 was not broken as badly. The best attack is, as I recall, 2^63, which is computationally infeasible without special-purpose hardware. special purpose? or lots of commodity? like the Amazon-EC2 example used in the cert issue? (or PS3s or...) No -- special-purpose chips, along the lines of Deep Crack (http://en.wikipedia.org/wiki/EFF_DES_cracker). Let's do the arithmetic. 'openssl speed sha1' on my desktop -- a 3.4 Ghz Dell -- manages 1583237 16-byte blocks in 2.92 seconds, or ~542204/second. Let's assume that for an attack to be economical, the calculations have to be completed within 30 days. My machine could do 1405B hashes in that time frame. But I need 2^63 of them, which means I need 6.5 million machines cooperating. Not impossible for BOINC, but I don't think that EC2 could handle it. (b) Per a paper Eric Rescorla and I wrote, there's no usable alternative, since too many protocols (including TLS) don't negotiate hash functions before presenting certificates. In particular, this means that a web site can't use SHA-256 because (1) most clients won't support it; and (2) it can't tell which ones do. (Note that this argument applies just as much to combinations of hash functions -- anything that *the large majority of today's* browsers don't implement isn't usable.) This is a function of an upgrade (firefox3.5 coming 'soon!') for browsers, and for OS's as well, yes? So, given a future flag-day (18 months from today no more MD5, only SHA-232323 will be used!!) browsers for the majority of the market could be upgraded. Certainly there are non-browsers out there (eudora, openssl, wget, curl..bittorrent-clients, embedded things) which either will lag more or break all together. Have you looked at the statistics on upgrades lately? Not a pretty picture... See, among others, http://www.ews.uiuc.edu/bstats/latest.html http://www.upsdell.com/BrowserNews/stat_trends.htm http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2 http://www.techzoom.net/publications/insecurity-iceberg/index.en These two points lead us to (c): security is a matter of economics, not algorithms. Switching now to something else loses more in connectivity or customers than you would lose from such an expensive attack. only if not staged out with enough time to roll updates in first, right? From all the data I've seen, very many machines are *never* upgraded, so the proper metric for enough time is computer lifetime. Firefox 3 does handle SHA-256/384/512; I don't think IE7 does. --Steve Bellovin, http://www.cs.columbia.edu/~smb
NANOG 45: ISP Security BOF - Call for participants
Hello and Happy New Years all, NANOG 45 is fast approaching and so here is the call for participants for the ISP Security BOF. This is *your* chance to talk about interesting security related topics and provide some feedback on what you would (and would not) like to hear about... Some security thing been buggin' you all year? Some topic that you feel strongly about and would like a change to inform others about? Step right up and give a talk... Slides are welcome, but not required... W
Re: Security team successfully cracks SSL using 200 PS3's and MD5
Christopher Morrow wrote: This is a function of an upgrade (firefox3.5 coming 'soon!') for browsers, and for OS's as well, yes? So, given a future flag-day (18 months from today no more MD5, only SHA-232323 will be used!!) browsers for the majority of the market could be upgraded. Certainly there are non-browsers out there (eudora, openssl, wget, curl..bittorrent-clients, embedded things) which either will lag more or break all together. I think you might be downplaying the size of the problem here. X.509 and TLS/SSL isn't just used for browsers, but for a wide variety of places where there is a requirement for PKI based security. So when you talk about a flag day for dealing with SHA-X (where X != 1), have you considered the logistical problems of upgrading all those embedded devices around the world? The credit card terminals? The tiny CPE vpn units? The old machine in the corner which handles corporate sign-on, where the vendor has now gone bust and no-one has the source code. And the large web portal which had a whole bunch of local apache customisations based on apache 1.3.x and where the original developers left for greener pa$ture$, and no-one in-house really understands what they did any longer. Etc, etc. It's different if you have a protocol which allows parameter negotiation to deal with issues like this, but not so good when you don't. Nick
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
On Jan 3, 2009, at 12:46 PM, Frank Bulk wrote: For me the MD5 hashes on file downloads are more valuable to ensure the package is accurate to a byte rather than to verify its authenticity or integrity. Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost complete confidence that the file is the original one? I don't think anyone has been able to create a duplicate file that generates the same SHA-1 *and* MD5 hashes as the original file. I would not be too sure. MD5 only makes one pass over the data. Suppose that I find two messages, M1 and M2, that have the same MD5 hash - there are methods out there to do that. M1 is the good message, M2 is the bad message. Let || be the concatenation operator. So, for any string S M1||S and M2||S have the same MD5 hash. So, if I can find an S such that the SHA-1 hash for M1||S and M2||S are the same, the MD5 hashes for these messages will still be the same, and you have your feared condition. My understanding is that one type of collision search involves using an S and trying to find collisions of M1 and M2||S by varying S. Modifying this to a common S does not seem that different, and I would not want to bet a lot on it being fundamentally much more difficult. (It might be, it might not be, I have no idea, the question is, how much are you willing to bet on it ?) Regards Marshall Regards Marshall Frank -Original Message- From: Florian Weimer [mailto:f...@deneb.enyo.de] Sent: Saturday, January 03, 2009 10:23 AM To: Skywing Cc: NANOG Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files.
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
* Hank Nussbacher: On Fri, 2 Jan 2009, Mikael Abrahamsson wrote: MD5 is broken, don't use it for anything important. You mean like for BGP neighbors? Good point. However, as a defense against potential blind injection attacks, even an unhashed password in a TCP option would do the trick (at least in the non-IXP case, IXPs may pose different challenges). Wanna suggest an alternative? :-) Just switch on IPsec. 8-)
Re: Security team successfully cracks SSL using 200 PS3's and MD5
* Nick Hilliard: I think you might be downplaying the size of the problem here. X.509 and TLS/SSL isn't just used for browsers, but for a wide variety of places where there is a requirement for PKI based security. So when you talk about a flag day for dealing with SHA-X (where X != 1), have you considered the logistical problems of upgrading all those embedded devices around the world? They won't be affected by the flag day, because the flag day is set by the relying party (that is, the browser), not the CA. If you've got a real PKI deployment, by definition, you've got procedures to deal with sudden advances in published cryptanalysis (even if it involves posting guards at certain buildings, instead of relying on smartcards for access control). The problematic areas are those where cryptography is used to comply with some checklist (or for PR purposes), and not for its security properties. In those environments, algorithm changes can never justify the associated costs.
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
* Frank Bulk: For me the MD5 hashes on file downloads are more valuable to ensure the package is accurate to a byte rather than to verify its authenticity or integrity. Indeed. I've experienced that first-hand: the hashes helped to isolate a case of faulty router memory at the ISP I used at home. (The TCP checksum is very weak and does not detect bit errors which occur at multiples of 16 bits. If the probability of such errors is so high that two of them occur in a single segment, they very likely cancel out, which was exactly what I observed in the issue mentioned above.) Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost complete confidence that the file is the original one? I don't think anyone has been able to create a duplicate file that generates the same SHA-1 *and* MD5 hashes as the original file. For most applications, it's better to include a totally random string at the beginning of the message, before signing it, and strip it upon signature verification (or encode it in a way so that it is simply ignored by the application). The convergent property of hash functions (if, by chance, two people come up independently with the same document, it hashes to the same value) is rarely needed. A random string near the beginning means that the attacker doesn't know the initial internal state of the hash function when the collision is constructed, which should make attacks involving evil twins much, much harder. I expect that at a not too distant point in the future (say, within the next ten years), strong hashes keyed in a such a way offer very significant performance gains over non-keyed, but still strong hashes, so that most protocols which do not rely on the convergence property will switch to them. Convergence might even turn out to be too costly, not just in terms of performance, but in security. (And I write this as a frequent Git user. 8-/)
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
What's the cost to switching to something other than MD5 here, though? Just the general risk of change (sometimes referred to as bricking). The changes on the generating side have already been implemented. Maybe we should include a dummy package entry at the beginning of the package list, with unpredictable contents. This should be sufficient with the current level of cryptanalysis (like most folks, we are relatively unprotected against second preimage attacks because we still need to support MD5-only private repositories and OpenPGP V3 signing keys). It does not solve the problem that MD5 is an outcast these days, no matter how it is used. I agree that users not checking download links is likely more probablistic. But as checking the sums is already entirely a manual process, what's the trouble with switching to sha256 now abd stating this in the DSA mails? There are some folks who use scripts to parse the messages. But as I said, we are far more likely to drop .deb hashes altogether, probably as lenny is released. I have to admit that hearing that Debian's going to continue moving forward with md5 until an unspecified somewhen date in the future is a bit disappointing. Yes, I'd like to zap a magic wand and make all those MD5-only APT installations go away, but it isn't that easy.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Sat, Jan 3, 2009 at 1:41 PM, Nick Hilliard n...@foobar.org wrote: Christopher Morrow wrote: This is a function of an upgrade (firefox3.5 coming 'soon!') for browsers, and for OS's as well, yes? So, given a future flag-day (18 months from today no more MD5, only SHA-232323 will be used!!) browsers for the majority of the market could be upgraded. Certainly there are non-browsers out there (eudora, openssl, wget, curl..bittorrent-clients, embedded things) which either will lag more or break all together. I think you might be downplaying the size of the problem here. X.509 and I wasn't, not intentionally.. I was trying to address the problem which the researchers harped on, and which seems like the hot-button for many folks: oh my, someone can intercept https silently!! I understand there are LOTS of things out there using certs for all manner of not-http things. I also understand that by telling a browser class that they shouldn't accept anything but sha-X seems workable. I suppose having the CA's kick out ONLY SHA-X is a bad plan, but ... maybe letting cert requestors select the hash funciton (not md5) is better? (or a step in the right direction at least) TLS/SSL isn't just used for browsers, but for a wide variety of places where there is a requirement for PKI based security. So when you talk about a flag day for dealing with SHA-X (where X != 1), have you considered the logistical problems of upgrading all those embedded devices around the world? The credit card terminals? The tiny CPE vpn units? The old I had... yup. machine in the corner which handles corporate sign-on, where the vendor has now gone bust and no-one has the source code. And the large web portal which had a whole bunch of local apache customisations based on apache 1.3.x and where the original developers left for greener pa$ture$, and no-one in-house really understands what they did any longer. Etc, etc. It's different if you have a protocol which allows parameter negotiation to deal with issues like this, but not so good when you don't. agreed, 100%. There are also lots of folks using certs internally for all manner of oddball reasons... signed on their own CA (perhaps chained to a 'real' CA, perhaps not). They'll have to be accomodated as well, of course. -chris
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
On Sat, 03 Jan 2009 17:23:06 +0100, Florian Weimer said: Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. More to the point - there are known easy ways for an attacker to generate *two* documents that have the same MD5 hash (the basis of this attack). However, the attacker has no control over what the actual value of that MD5 hash is. What's *not* still feasible is for an attacker to take Debian's data and the already-generated MD5 hash, and create a second file that hashes to that same already-known hash. At that point, it's probably easier to just attack the trusted infrastructure in an attempt to recover the GnuPG private key, and then just sign your evil replacement package. There's 2 advantages to this attack: 1) It doesn't *matter* if they PGP-sign the file with the MD5 hashes or if the file has SHA1 or SHA512 - the signature will look fine. 2) It's been proven doable to at least one major distro in the past few months. pgpMgKviyAY5C.pgp Description: PGP signature
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: On Sat, 3 Jan 2009, Hank Nussbacher wrote: You mean like for BGP neighbors? Wanna suggest an alternative? :-) Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all. But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term. Who is working on this? I don't find anything here: http://www.ietf.org/html.charters/idr-charter.html All I can find is: http://www.ietf.org/rfc/rfc2385.txt http://www.ietf.org/rfc/rfc3562.txt http://www.ietf.org/rfc/rfc4278.txt Nothing on replacing MD5 for BGP. -Hank
