RE: HSM outage causes root CA key loss
Hi, >>Our current Server CA certificate will expire in 2026 (when hopefully it >>won't be my problem!). > >Thus the universal CA root cert lifetime policy, "the lifetime of a CA root >certificate is the time till retirement of the person in charge at its >creation, plus five years" :-). This neglects the not entirely unlikely possibility that long before your retirement some clever person will have broken your cryptographic hash function or signature scheme. I once saw a document refering to a PKI with a proposed certificate lifetime of 100 years. Those people really care about their grandchildren. Grtz, Benne - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: HSM outage causes root CA key loss
Hi, > reports that the PKI for their electronic health card has > just run into > trouble: they were storing the root CA key in an HSM, which > failed. They now have a PKI with no CA key for signing new > certs or revoking existing ones. Suppose this happens in a production environment of some CA (root or not), how big a problem is this? I can see two issues: - they have to build a new CA and distribute its certificate to all users, which is annoying and maybe costly but not a security problem, - if they rely on the CA for signing CRLs (or whatever revocation mechanism they're using) then they have to find some other way to revoke existing certificates. No need to revoke any certificate. Any other problems? Maybe something with key rollover or interoperability? Seems to me that for signing CRLs it's better to have a separate "Revocation Authority" (whose certificate should be issued by the CA it is revoking for); then revoking can continue when the CA loses its private key. The CA still may have revoking authority as well, at least to revoke the Revocation Authority's certificate... Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: Property RIghts in Keys
Hi all, > Say I have discovered a marvelous method of easily factoring > RSA keys, which unfortunately the margin of this emacs buffer > is too small to contain, and I then go out, factor GeoTrust's > CA key and issue a new certificate. > > Questions: > > Am I now infringing on GeoTrust's IP rights? Or have, rather, > I made myself a co-owner in said rights on this particular key? > > Have I broken any law? If not, should what I have done be illegal? Here's a variant that I find interesting ;-). It's not about the public key but about the signature, another cryptograhic field in a certificate that shares many properties with keys. Say somebody has discovered a marvelous method of finding collisions for a hash function. Then he creates two certificates, of which the to-be-signed parts form a hash collision. Then he lets a CA sign one of them, and copies the signature into the other one, making that a certificate that is indistinguishable from a valid one issued by the CA. Has he broken any copyright law? I admit this is a purely hypothetical case. Or... maybe it isn't? Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Hi Peter, > 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" I had algorithms in mind, as the 'hash crisis' is about algorithms. For algorithms the situation might be simpler than for protocols. It is conceivable that one of these days some clever person comes up with, say, a practical chosen-prefix collision attack on SHA-1, enabling something similar as we did with MD5. It is also conceivable that some clever person completely breaks Rijndael, or RSA. Do software vendors (such as browser vendors) and service providers (such as CAs) have disaster recovery plans for such a situation? Or are these simply 'accepted risks' that nobody worries about? In my view it would be prudent to move SHA-1 out of the no-worry category. One level up, and maybe an example of a general lesson James was asking for: good practice to avoid availability problems is to add redundancy. In hash functions the security in many applications now seems to be completely based on SHA-1, a not-yet-broken but known-to-be-weak algorithm. How can we avoid such situations? (I am thinking long term here). 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? I was not around when Rijndael was chosen as the AES winner. Have there been discussions then about the number of winning algorithms? Why only one, and not three winners, say, with a sufficiently different design, that everybody then will implement? Can / should NIST do so with SHA-3? Is implementing three new hash functions at the same time much more complicated than implementing one? Grtz, Benne de Weger - 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
Short announcement: MD5 considered harmful today - Creating a rogue CA certificate
Hi all, Today, 30 December 2008, at the 25th Annual Chaos Communication Congress in Berlin, we announced that we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the commercial root CAs that browsers trust by default. We were able to do so by constructing a collision for the MD5 hash function, obtaining a valid CA signature in a website certificate legitimately purchased from the commercial CA, and copying this signature into a CA certificate constructed by us such that the signature remains valid. For more information about this project, see http://www.win.tue.nl/hashclash/rogue-ca/. The team consists of: Alexander Sotirov (independent security researcher, New York, USA), Marc Stevens (CWI, Amsterdam, NL), Jacob Appelbaum (Noisebridge, The Tor Project, San Francisco, USA), Arjen Lenstra (EPFL, Lausanne, CH), David Molnar(UCB, Berkeley, USA), Dag Arne Osvik (EPFL, Lausanne, CH), Benne de Weger (TU/e, Eindhoven, NL). For press and general inquiries, please email md5-collisi...@phreedom.org. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RSA modulus record
Hi, There's a new biggest known RSA modulus. It is (in hexadecimal notation): FF...(total of 9289166 F's)...FFDFF...(total of 1488985 F's)...FF800...(total of 9289165 0's)...001 It is guaranteed to be the product of two different large primes, and it has more than 80 million bits. Impressive security... Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: PlayStation 3 predicts next US president
Hi William, > > ... We say so on > > the website. We did show this hiding of collisions for other data > > formats, such as X.509 certificates > > More interesting. Where on your web site? I've long abhorred the > X.509 format, and was a supporter of a more clean alternative. See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/ > > Our real work is chosen-prefix collisions combined with > > multi-collisions. This is crypto, it has not been done before, > > Certainly it was done before! I was referring to MD5. Apart from that, I'd be interested in seeing references to older work on chosen-prefix multicollisions. > What *would* be crypto is the quantification of where MDx > currently falls on the computational spectrum. Our first chosen-prefix collision attack has complexity of about 2^50, as described in our EuroCrypt 2007 paper. This has been considerably improved since then. In the full paper that is in preparation we'll give details of those improvements. Grtz, Benne - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: PlayStation 3 predicts next US president
Hi William, > > The attack was to generate a multitude of predictions for the US > > election, each of which has the same MD5 hash. If the certifier > > certifies any one of these predictions, the recipient can use the > > certificate for any one of these predictions. > > > That's a mighty big "if" -- as in infinite improbability. > Therefore, a parlor trick, not cryptography. That's an "if" indeed, we say so on the website. How big it is, you all form your own opinion. > There are no circumstances in which any reputable certifier > will ever certify any of the "multitude" containing a hidden > pdf image, especially where generated by another party. This I read as a definition of 'reputable'. > While there are plenty of chosen text attacks in > cryptography, this one is highly impractical. The image is > hidden. It will not appear, and thus would not be > accidentally copied by somebody (cut-and-paste). > > The parlor trick demonstrates a weakness of the pdf format, not MD5. I disagree. We could just as easy have put the collision blocks in visible images. We could just as easy have used MS Word documents, or any document format in which there is some way of putting a few random blocks somewhere nicely. We say so on the website. We did show this hiding of collisions for other data formats, such as X.509 certificates and for Win32 executables. Our real work is chosen-prefix collisions combined with multi-collisions. This is crypto, it has not been done before, this is as far as we can get in MD5 cryptanalysis, and we think it's relevant. To sell it to the world we wrapped it up nicely. You just throw away the wrapper. Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
PlayStation 3 predicts next US president
Hi all, We (Marc Stevens, Arjen Lenstra and me) have used a Sony PlayStation 3 to correctly predict the outcome of the 2008 US presidential elections. See http://www.win.tue.nl/hashclash/Nostradamus if you want to know the details of what this has to do with cryptography. We also announce two different Win32 executables that have identical MD5 hash values. This can be made to happen for any two executable files. This implies a vulnerability in software integrity protection and code signing schemes that still use MD5. See http://www.win.tue.nl/hashclash/SoftIntCodeSign for details. Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: [Cfrg] Applications of target collisions: Pre or post-dating MD5-based RFC 3161 time-stamp tokens
Hi Steven, > So how close are we getting to first or second preimage attacks? As far as we know, not one bit closer. Best known attack on MD5 preimage resistance still is brute force. You may interpret our result as enlarging the applicability of collision attacks. In that sense the gap to preimage attacks has diminished. But we have no measure available to tell by how much. Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
target collisions and colliding certificates with different identities
Hi all, We announce: - an example of a target collision for MD5; this means: for two chosen messages m1 and m2 we have constructed appendages b1 and b2 to make the messages collide under MD5, i.e. MD5(m1||b1) = MD5(m2||b2); said differently: we can cause an MD5 collision for any pair of distinct IHVs; - an example of a pair of valid, unsuspicious X.509 certificates with distinct Distinguished Name fields, but identical CA signatures; this example makes use of the target collision. See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/, where the certificates and a more detailed announcement can be found. Marc Stevens Arjen Lenstra Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
SHA1 coll
Hi All, The following two byte-strings (differing in a few bits only): 59 6F 75 20 61 72 65 20 41 70 72 69 6C 20 46 6F 6F 6C 20 6E 6F 2E 20 30 30 36 39 30 30 32 35 31 33 31 00 and 59 6F 75 20 61 72 65 20 41 70 72 69 6C 20 46 6F 6F 6C 20 6E 6F 2E 20 31 37 38 36 37 33 32 39 32 31 39 00 both have SHA-1 20060401 For more explanation, visit http://deweger.xs4all.nl/20060401.html Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
MD5 collisions in one minute
Hi all, You might be interested in knowing that my MSc student Marc Stevens has found a considerable speedup of MD5 collision generation. His improvements of Wang's method enables one to make MD5 collisions typically in one minute on a PC; sometimes it takes a few minutes, and sometimes only a few seconds. His paper (shortly to appear on the Cryptology ePrint Archive) can be found on http://www.win.tue.nl/hashclash/, where we've also made his software available (source code and a Win32 executable). Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Nonrepudiation - in some sense
Hi all, > > server, and re-encrypting the information. Moreover, it > > maintains the non-repudiation of transactions since the > > encrypted communication is between client and application with > > no proxy acting as middleman. > > Firstly, even if you believe that _any_ crypto provides > non-repudiation > (see http://www.apache-ssl.org/tech-legal.pdf for a paper I > co-authored > on this and other stuff - executive summary: I don't believe it), you > can't "maintain" the non-repudation of SSL because it doesn't provide > non-repudation. > > Secondly, obviously, you can only decrypt SSL if you have the private > key, so presumably this is referring only to incoming SSL connections. Moreover, it seems to me that: 1. it is misleading (at least in general) to state that SSL operates "between client and application". SSL operates between client (browser) and (web) server; in many cases the real application might be on another server, way behind the point where the SSL connection terminates. Are there any SSL-aware "applications" (i.e. implementing business logic rather than providing communication services) for which this solution may be useful? 2. it is misleading to state that SSL secures "transactions". SSL secures "sessions". The authentication of SSL applies only to the session handshake, not to the exchanged data, in which "transaction" data might be present. This is why (as Ben remarks) SSL does not provide non-repudiation. 3. with this solution you need your private key in at least two different places. This introduces essentially more complicated key management, and increases the risk of key compromise. Grtz, Benne de Weger = Technische Universiteit Eindhoven Coding & Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer: HG 9.84 tel.: (040) 247 2704, bgg 5141 e-mail: [EMAIL PROTECTED] www:http://www.win.tue.nl/~bdeweger = - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Smooth prime MD5 collisions
Hi Ben, Looks like this is essentially the same as, or at least very similar to, what Arjen Lenstra and I did in Section 4 of the full version of our paper "On the possibility of constructing meaningful hash collisions for public keys", see http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf. The proceedings version of this paper (presented at ACISP 2005, proceedings in Springel LNCS 3574) skipped that section due to space limitations. Grtz, Benne de Weger = Technische Universiteit Eindhoven Coding & Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer: HG 9.84 tel.: (040) 247 2704, bgg 5141 e-mail: [EMAIL PROTECTED] www:http://www.win.tue.nl/~bdeweger = > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie > Sent: vrijdag 21 oktober 2005 1:40 > To: Cryptography > Subject: Smooth prime MD5 collisions > > Inspired by http://www.links.org/?p=12#comments, I have just produced > this prime: > > D131DD02C5E6EEC4693D9A0698AFF95C2FCAB50712467EAB4004583EB8FB7F > 8955AD340609F4B30283E4888325F1415A085125E8F7CDC99FD91DBD728037 > 3C5BD8823E3156348F5BAE6DACD436C919C6DD53E23487DA03FD02396306D2 > 48CDA0E99F33420F577EE8CE54B67080280D1EC69821BCB6A8839396F965AB > 6FF72A700AD6BF4FE0D1559E6140208D6D2BA4694335 > > which I claim collides (using the well-known alternative block) with a > number that has the first 26 primes as factors. > > Also, while I was writing this, I got: > > D131DD02C5E6EEC4693D9A0698AFF95C2FCAB50712467EAB4004583EB8FB7F > 8955AD340609F4B30283E4888325F1415A085125E8F7CDC99FD91DBD728037 > 3C5BD8823E3156348F5BAE6DACD436C919C6DD53E23487DA03FD02396306D2 > 48CDA0E99F33420F577EE8CE54B67080280D1EC69821BCB6A8839396F965AB > 6FF72A700085EDE28444505E3FE8D0F8D68EFF7CF302ECEE5FCCFA78FA > E6BF0F897957F7CD21 > > which collides with 43 primes. > > Code and stuff will follow, but now I'm going to bed. I expect its > obvious how they are made, anyway. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "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] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Collisions for hash functions: how to exlain them to your boss
Hi Eric, Technically speaking you're correct, they're signing a program. But most people, certainly non-techies like Alice's boss, view postscript (or MS Word, or ) files not as programs but as static data. In being targeted at non-techies I find this attack more convincing than those of Mikle and Kaminsky, though essentially it's a very similar idea. Note that opening the postscript files in an ASCII-editor (or HEX-editor) immediately reveals the attack. Stefan Lucks told me they might be able to obfuscate the postscript code, but again this will only fool the superficial auditor. Grtz, Benne = Technische Universiteit Eindhoven Coding & Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer HG 9.84 tel. (040) 247 2704, bgg 5141 e-mail: [EMAIL PROTECTED] www: http://www.win.tue.nl/~bdeweger = > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla > Sent: maandag 13 juni 2005 17:05 > To: Stefan Lucks > Cc: cryptography@metzdowd.com > Subject: Re: Collisions for hash functions: how to exlain > them to your boss > > Stefan Lucks <[EMAIL PROTECTED]> writes: > > Magnus Daum and myself have generated MD5-collisons for > PostScript files: > > > > http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ > > > > This work is somewhat similar to the work from Mikle and > Kaminsky, except > > that our colliding files are not executables, but real documents. > > > > We hope to demonstrate how serious hash function collisions > should be > > taken -- even for people without much technical background. > And to help > > you, to explain these issues > > > > - to your boss or your management, > > - to your customers, > > - to your children ... > > While this is a clever idea, I'm not sure that it means what you imply > it means. The primary thing that makes your attack work is that the > victim is signing a program which he is only able to observe mediated > through his viewer. But once you're willing to do that, you've got a > problem even in the absence of collisions, because it's easy to write > a program which shows different users different content even if you > without hash collisions. You just need to be able to write > conditionals. > > For more, including an example, see: > http://www.educatedguesswork.org/movabletype/archives/2005/06/ > md5_collisions.html > > -Ekr > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Anti-colliding certificates
Hi All, It's nice to see that my message on anti-colliding certificates finally got through. To fully appreciate its contents you should set back your internal clock to the date the message was originally sent. Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
new result: "anti-colliding" x.509 certificate
Hi all, Today I announce the construction of a valid X.509 certificate, based on the MD5 hash function, that allows two different digital signatures on the (identical) "to-be-signed" part. This is based on a new technique of constructing MD5-anti-collisions. For details, see http://www.win.tue.nl/~bdeweger/AntiCollidingCertificates/. This type of certificate is called "anti-colliding", as this is complementary to a construction, announced one month ago, of "colliding x.509 certificates", i.e. two different X.509 certificates with identical signatures, based on MD5-collisions. See http://www.win.tue.nl/~bdeweger/CollidingCertificates/. Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Colliding X.509 Certificates
Hi Joerg, > My concern is not MD5, its SHA-1. I don't see that we can get rid of > SHA-1 in certificates in the next 5 years: > * None of the alternatives is widely implemented today. > * For controlled environments like in-house applications you might be > able to switch earlier (0-2 years). > * In open environments like inter company S/MIME or public facing SSL > servers it will take years before you can assume that people > are able to > verify non SHA-1 certs. > * For CA certificates you'll have to add more years (not to > speak about > those CA certs with notAfter=2038). > > From this perspective it makes sense to think about > operating a CA with > a broken hash function, I believe. > * Technically SHA-1 is broken today. > * I don't fear that anybody might attack my CA based on the > attack known > today. > * But given the progress in the last year I personally expect the > attacks on SHA-1 to get more practical. It makes sense to do a risk analysis, based on a.o. * how critical is the particular application to the business * what threats are there (who might try something bad) * what's the user community (in-house or the entire world or something in between) and then accept a certain residual risk of continuing the use of 'broken' hash functions for some more time. At the same time it is wise to start deploying better hash functions. I hope the Microsofts and Suns and of this world are working on this right now. It's clear that this is going to take a long time and cost a lot of money. We're very lucky that the present attacks are still to a large extent theoretical in nature, and do not (yet) lead to realistic attack scenarios (at least we couldn't think of one, and we haven't seen anybody else coming up with one). The main lesson to be learnt here is that we have made our systems too dependent on a few cryptographic primitives only; much more flexibility is needed. One of these days some smart person may come up with a real attack on , then you cannot afford two years to change your systems. So I still think that the message we should send into the world is to phase out MD5 now, and SHA-1 a.s.a.p. (NIST says: by 2010, that sounds very long to me). If you cannot do that for practical reasons, then that's your risk. When you accept that risk, that's fine with me. Apart from that I've never understood why there are CA certificates with such incredibly long lifetimes. That's simply asking for trouble. > > A relying party cannot find out from the certificate alone whether > > it has a "twin sister" or not. The fact that there is a > random-looking > > serial number doesn't help you there. > That is true, and its certainly not nice. But I think the > real concern > of the relying party is not specifically about certificates with the > same hash, its about > * the correctness of the contents (name of private key holder > etc.) and > * the existance of other certificates issued to same key but > different > name, which might be used to repudiate signatures, e.g. > > The relying party always needs to trust the CA on those two > properties, > as the CA can easily issue certs with incorrect conents, it > doesn't need > hash collisions for that. > > My question is: Can a CA prevent "twin sisters" from coming into > existance by using my proposed procedure? With current knowledge the answer is: yes. Randomized serial numbers will be sufficient. And indeed: a CA doesn't need hash collisions to do real damage. Grtz, Benne = Technische Universiteit Eindhoven Coding & Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer HG 9.84 www: http://www.win.tue.nl/~bdeweger = - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Colliding X.509 Certificates
Hi Joerg, It's true that our 'attack' assumes that the attacker has sufficient control over the CA, in particular over setting DN's, serial numbers and the validity period. Yet I have a few remarks on this. A relying party cannot find out from the certificate alone whether it has a "twin sister" or not. The fact that there is a random-looking serial number doesn't help you there. A newly issued certificate based on MD5 should not be trusted anymore anyway. The only reasonable measure against collision-based attacks is to declare MD5 dead. It's better to bury it than to try keeping it alive. I have nothing against randomized serial numbers. But your security should be based on better ideas. And it's just as easy to avoid broken hash functions. Grtz, Benne de Weger > -Original Message- > From: Joerg Schneider [mailto:[EMAIL PROTECTED] > Sent: vrijdag 11 maart 2005 11:52 > To: Olle Mulmo > Cc: Weger, B.M.M. de; cryptography@metzdowd.com > Subject: Re: Colliding X.509 Certificates > > Olle Mulmo wrote: > > Seems to me that a CA can nullify this attack by choosing a serial > number or RDN component (after all, a CA should vet the DN and not > simply sign what's in the PKCS#10 request), such that the public key > does not end up at an "appropriate" DER-encoded offset in the > > certificate. Or am I completely lost? > > Yes, there seem to several possibilities to defend against > this kind of > attack in a real world scenario. Modifying the subject DN in a way > un-predictable by the attacker is one of them. For Benne's > attack it would > be enough to modify its length, so that the public key > doesn't get to the > required offset. > > I would like to have a general way to fend off collision attacks on > certificates. To this end I propose that the CA generates the > certificate > serialNumber in a way that cannot be guessed. Some CAs are > already doing > this, I guess mainly to prevent people from seeing how many certs they > issue. > > There are several advantages of using the serialNumber: > * it has no semantics that we might break, as long as we make sure it > stays unique > * it is one of the first items in a certificates, before any > content an > attacker might control > * its no problem to make it e.g. 128 bits long > > By putting an un-guessable value in the serialNumber, the attacker is > faced with a similar problem as with a HMAC, which people > believe are not > affected by the known collision attacks. For this reason I > believe with > un-guessable serialNumbers, we should be safe to use a hash function, > which is not collision resistant, as long as it is 2nd pre-image > resistant. > > Its rather easy to implement un-guessable servialNumbers: > * use a cryptographically strong PRNG (and keep the seed > secret) or TRNG > * encrypt a counter with a block cipher (and keep the key secret) > > Best regards, > > Jörg > > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Colliding X.509 Certificates
Hi all, We announce the construction of two different valid X.509 certificates that have identical signatures. This is based on MD5 collisions. One could e.g. construct the to-be-signed parts of the certificates, and get the one certificate signed by a CA. Then a valid signature for the other certificate is obtained, while the CA has not seen proof of possession of the private key of this second certificate. The certificates we constructed can be downloaded from http://www.win.tue.nl/~bdeweger/CollidingCertificates/. >From this site some more technical information can be downloaded as well. We provide a short paper explaining in detail our method. It is available on the website, and on the Cryptology ePrint Archive, at http://eprint.iacr.org/2005/067. This is joint work with Arjen Lenstra (Lucent Bell Labs and TU Eindhoven) and Xiaoyun Wang (Shandong University). Grtz, Benne de Weger = Technische Universiteit Eindhoven Coding & Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven e-mail: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] www: http://www.win.tue.nl/~bdeweger = - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: public-key: the wrong model for email?
Hi Ed, What about ID-based crypto: the public key can be any string, such as your e-mail address. So the sender can encrypt even before the recipient has a key pair. The private key is derived from the public key by a trusted party when the recipient asks for it. Yes, the recipient does have some burden here, but it seems to me that that is unavoidable. I'm not saying that this is without problems (private key distribution, inherent key escrow / recovery, revocation issues), or that it's easier manageable than traditional PKI, but it may solve some of your issues. The idea for ID-based crypto comes from Adi Shamir, back in 1984. The first practical and mathematically sound realisation is due to Boneh and Franklin (Crypto 2001), and is brought to the market by Voltage (www.voltage.com). I don't know their products, only that it exists, and I'm not a shareholder. I do think it's interesting math and interesting crypto, and that it could lead to interesting technology. Grtz, Benne de Weger = Technische Universiteit Eindhoven Coding & Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer HG 9.84 tel. (040) 247 2704, bgg 5141 e-mail: [EMAIL PROTECTED] www: http://www.win.tue.nl/~bdeweger = > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck > Sent: woensdag 15 september 2004 20:39 > To: [EMAIL PROTECTED] > Subject: public-key: the wrong model for email? > > [Perry: please use this version, if possible] > > Public-key cryptography burdens the recipient and puts the > recipient in charge, while the sender is at the recipient's > mercy. Is this the right model for email security? After all, > the sender is the party at risk. > > To clarify, my comment is not that PKC is not useful for > email. I believe it is, but not directly used as it is today. > > What I am saying is that the problem is key distribution. I > want to separate the key distribution solution as directly > done by PKC today (send the public-key) from a possible > general solution for PKC key distribution that does not > require sending the public-key. The point is that when PKC > solves this problem directly, it solves it in a way that's > useful for webservers (the webserver does not have to trust > the client's certificate) but presents difficulties for email > senders (the sender has to trust the recipient's > certificate). Email use of PKC treats the recipient as a server. > > I think that what we need is a key distribution method for > email (that can still use PKC and PKI) where, because the > sender has all the risk, the sender defines how email is > secured and delivered. The recipient should always be able to > receive it, without too much burden or required previous work. > > For example, let's see how FedEx works. The sender chooses > the service and the type of envelope to protect the message. > The sender also chooses the instructions that must be > followed before the envelope can be opened by the recipient. > The recipient has no charge to pay for, or burden, in order > to receive the envelope, and does not have to do anything > before the envelope is sent. The recipient is able to verify > the identity of the sender and, if so desired, refuse the > envelope. The recipient can open the envelope if and only if > the recipient is willing to follow the sender's instructions > (e.g., providing name, address, date, signature). > > Yes, SSL and public-key encryption are and continue to be a > success for web servers. However, the security model for > protecting email with public-key cryptography seems to be > backwards, technically and business wise. The sender, who is > the party at risk, has to trust a lock provided by the recipient (his > public-key) to protect her secrets (the message). If FedEx > would provide message security a la PGP, PGP/MIME or S/MIME > email, the sender would have to convince the recipient to pay > and send in advance an envelope for the sender to use. > The sender, however, would never know whether the envelope > indeed prevented others from prying into its contents. > > A better situation would arise if the lock (i.e., the > envelope) would be controlled by the sender. Moreover, the > recipient is not the business driver who needs to provide, > pay for and protect the lock. The sender is the party who has > the motivation to spend money to provide and protect the lock. > > In short, I find that public-key cryptography cannot solve > the security issues of email when used as it is today and, > most importantly, cannot provide the needed motivation for > users, senders and recipients, to buy into it. > > It's not a matter of improvements in usability, better > pricing or user education [1]. It simply does not work as it > should work. That's also why, IMO, it does not
