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 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: [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]
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: 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 name your favourite document format that allows macros) 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]
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 name your favourite software factory 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 name your favorite cryptographic primitive, 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 take off. It is using the wrong mathematics for the problem. Does