Re: Security by asking the drunk whether he's drunk
At 10:19 PM -0500 12/30/08, Jerry Leichter wrote: Robert Graham writes in Errata Security (http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html) that the attack depends on being able to predict the serial number field that will be assigned to a legitimate certificate by the CA. That part is true. Only a few CA's use predictable serial numbers That part, I think, is wrong. I looked into this a bit earlier this month and found that most of the ones I looked at are still using sequential numbers. - the field is actually arbitrary text If by arbitrary text you mean a non-negative integer. and need only be certainly unique among all certificates issued by a given CA. True as well. So: The current attack is only effective against a very small number of CA's which both use MD5 *and* have predictable sequence numbers. The attack is on end users who trust a root store that has a trust anchor from *any single* CA that uses MD5 and has predictable sequence numbers. The attack lets the attacker become a subordinate CA for that CA. At that point, the attacker can issue their own certs for any purpose. So the sky isn't falling It never does. That's why it is the sky. - though given how hard it is to decertify a CA (given that the known good CA's are known to literally billions of pieces of software, and that hardly anyone checks CRL's - and are there even CRL's for CA's?) this is certainly not a good situation. There are not CRLs for CAs. That's why is it is a root store. Oh, and how do you create a definitive list of CAs that use MD5 in their signatures? This also doesn't mean that, now that the door has been opened, other attacks won't follow. In fact, it's hard to imagine that this is the end of the story Quite right. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A History of U.S. Communications Security
Pehr Söderman wrote: Freshly declassified and a rather interesting read: A History of U.S. Communications Security (Volumes I and II, 1973) David G. Boak Lectures, National Security Agency (NSA) http://www.governmentattic.org/2docs/Hist_US_COMSEC_Boak_NSA_1973.pdf (From Bruce Schneier/Governmentattic) I like the informal style of the document, it's an easy read, even if one is not an intelligence buff. In the first volume, all but the first and last chapters are redacted (what is left is an introduction and TEMPEST). The second volume is more intact, and has some history DES, and a view on public key cryptography before affordable general computers. Certainly other things of which I don't realize the significance... Some of the redactions may be easily guessable, I fancy iron curtain, embassy, and later Russia on page 97. Why do they even bother? This would be a good exercise for some student to write a program doing a dictionary attack on the text using the properties of the used font. The last page has a puzzle, an innocent text system (steganography). Didn't solve it yet, but I think I found the clue, a misspelling of be advised to he advised. Thanks, Marcus - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today
On Tue, 30 Dec 2008, Hal Finney wrote: - The attack relies on cryptographic advances in the state of the art for finding MD5 collisions from inputs with different prefixes. These advances are not yet being published but will presumably appear in 2009. To insert a malicious basicConstraints CA = TRUE these advances appear necessary; I do not believe that they are necessary for the other very similar attack (where the malicious cert is a wildcard (*) certificate). I could be wrong about this, but I also don't think that the advances in cryptography to get from chosen prefix attacks to here are anywhere near as great as were needed to get the original chosen prefix work. We can evaluate the correctness of that statement when the work is published, of course. - The collision was found using Arjen Lenstra's PlayStation Lab and used 200 PS3s with collectively 30 GB of memory. The attack is in two parts, a new preliminary birthdaying step which is highly parallelizable and required 18 hours on the PS3s, and a second stage which constructs the actual collision using 3 MD5 blocks and runs on a single quad core PC, taking 3 to 10 hours. Prof. Lenstra's PlayStation Lab is definitely impressive, but there are many ways to get the computation time needed to perform this attack, including Amazon's EC2, botnets, and other high powered computing systems. It's not *that* much computation time. My take on this is that because the method required advances in cryptography and sophisticated hardware, it is unlikely that it could be exploited by attackers before the publication of the method, or the publication of equivalent improvements by other cryptographers. If these CAs stop issuing MD5 certs before this time, we will be OK. Once a CA stops issuing MD5 certs, it cannot be used for the attack. Its old MD5 certs are safe and there is no danger of future successful attacks along these lines. As the paper notes, changing to using random serial numbers may be an easier short-term fix. I am worried that this may be too optimistic of an outlook. This attack was known and discussed by at least two research teams for at least a year (Dan Kaminsky, Meredith L. Patterson, and I worked out the attack at the last CCC). To be fully confident in the CA infrastructure, all certificates that have delegated signing authority granted to them by a higher CA (using MD5 on the certificate in question) should be audited to ensure they are not malicious. This of course includes private certificate infrastructures, too. I would be extremely surprised if this attack had been performed prior to the original chosen prefix work being published -- but since that time, there has been plenty of opportunity for a malicious party to quietly perform this attack in the wild. --Len. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
