Re: [Cryptography] Thoughts about keys
So, how do I translate al...@example.org into a key? Once again, what do you think of namecoin? A bitcoin-like consensual database based on proof of work. If you also require proof-of-key via signature from the recipient, majority attacks make DoS easy, but identity stealing is still dependent on highly visible unsigned revocation certificates. At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. Then, each user can just broadcast his signature of the previously unpredictable consensual data, and various timestamping organizations can sign messages that say yes, I saw that at this time, maybe charging some tiny usage fee in the process. If a handshake is required (and in this case, it looks like it is), at least, prevent the organization from personalizing the cookie too much, by requiring it to have personal cookies be based on a digest of a common salt for all addresses, and data consensually associatable to the destination address. After a deadline, the organization publishes the definitive merkle tree digest of who was seen on time, together with the common salt. Third, presumably one wants a means to query such databases that doesn't allow traffic analysis. Mix networks including Tor are probably the answer on that. Without such a mechanism, listening in on the query traffic becomes a very good way to trace out social networks. Assuming a namecoin like system where every server has ALL the keys, your query could be of the form: give me all keys k such that digest(kmask)==digest(k0mask) with mask wide enough that you get say ~1000 keys, and computed in a deterministic/non-deterministic enough way that you don't leak too much information. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Reevaluate your ends periodically — if some of them or in contradiction with reality or with each other, abandon or amend them without mercy — and those you keep, pursue without any apology. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On 2013-09-01 9:11 PM, Jerry Leichter wrote: Meanwhile, on the authentication side, Stuxnet provided evidence that the secret community *does* have capabilities (to conduct a collision attacks) beyond those known to the public - capabilities sufficient to produce fake Windows updates. Do we know they produced fake windows updates without assistance from Microsoft? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Sep 1, 2013, at 6:06 PM, Perry E. Metzger wrote: We know what they spec for use by the rest of the US government in Suite B. http://www.nsa.gov/ia/programs/suiteb_cryptography/ AES with 128-bit keys provides adequate protection for classified information up to the SECRET level. Similarly, ECDH and ECDSA using the 256-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-256 provide adequate protection for classified information up to the SECRET level. Until the conclusion of the transition period defined in CNSSP-15, DH, DSA and RSA can be used with a 2048-bit modulus to protect classified information up to the SECRET level. AES with 256-bit keys, Elliptic Curve Public Key Cryptography using the 384-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-384 are required to protect classified information at the TOP SECRET level. Since some products approved to protect classified information up to the TOP SECRET level will only contain algorithms with these parameters, algorithm interoperability between various products can only be guaranteed by having these parameters as options. We clearly cannot be absolutely sure of what they actually use, but we know what they procure commercially. If you feel this is all a big disinformation campaign, please feel free to give evidence for that. I certainly won't exclude the possibility, but I find it unlikely. I'll make just a couple of comments: - Given the huge amount of material classified these days, SECRET doesn't seem to be a very high level any more, whatever its official definition. TOP SECRET still means a great deal though. But the really important stuff is compartmented (SCI), and Suite B is not approved for it - it has to be protected by unpublished Suite A algorithms. - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. (Same for DH and DSA.) It looks as if they are betting that factoring and discrete logs over the integers aren't as hard as people had thought. The whole business of AES-128 vs. AES-256 has been interesting from day one. Too many recommendations for using it are just based on some silly idea that bigger numbers are better - 128 bits is already way beyond brute force attacks. The two use the same transforms and the same key schedule. The only clear advantage AES-256 has is 4 extra rounds - any attack against the basic algorithm would almost certainly apply to both. On the other hand, many possible cracks might require significantly heavier computation for AES-256, even if the same fundamental attack works. One wonders NSA also wants SHA-384 - which is interesting given recent concerns about attacks on SHA-1 (which so far don't seem to extend to SHA-384). I don't want to get into deep conspiracy and disinformation campaign theories. My read of the situation is that at the time NSA gave its approval to this particular combination of ciphers, it believed they were secure. They seem to be having some doubts about RSA, DSA, and DH, though that could be, or could be justified as, ECC being as strong with much smaller, more practical, key lengths. Now, imagine that NSA really did find a way in to AES. If they were to suddenly withdraw approval for its use by the government, they would be revealing their abilities. A classic conundrum: How do you make use of the fruits of your cryptanalytic efforts without revealing that you've made progress? England accepted bombing raids on major cities to keep their crack of Enigma secret. So the continuation of such support tells us little. What will be interesting to see is how long the support continues. With work under way to replace SHA, a new version of the NSA recommendations will eventually have to be produced. Will it, for example, begin a phase-out of AES-128 for SECRET communications in favor of requiring AES-256 there as well? (Since there's no call so far to develop a cipher to replace AES, it would be difficult for NSA to recommend something else.) It's indeed a wilderness of mirrors, and we can only guess. But I'm very wary of using NSA's approval of a cipher as strong evidence, as the overall situation is complex and has so many tradeoffs. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote: At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. I don't understand why. The security requirement is that third parties must *not* be able to predict the token, because then they could sign the token without controlling the email address. The only organization that can know the cookie is actually the organization sending the cookie out. You appear to have inverted the security requirement... Then, each user can just broadcast his signature of the previously unpredictable consensual data, and various timestamping organizations can sign messages that say yes, I saw that at this time, maybe charging some tiny usage fee in the process. But then *anyone* could broadcast the token because anyone could have predicted it. It is difficult to make the interchange of the token and the reply itself widely witnessed -- the way around that is to have many organizations doing the interchanges so that one would have to suborn all of them. After a deadline, the organization publishes the definitive merkle tree digest of who was seen on time, together with the common salt. That is part of the envisioned model. Currently I'm looking at how to take advantage of the work already done on Certificate Transparency. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com wrote: - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. That is a misunderstanding. If you look at the way that the NSA specs these things, they try to keep all portions of a system of equal security so none is the weak point. A 2048 bit RSA key is factored vastly more easily than a 256 bit AES key is brute forced (that's just public knowledge -- try doing the back of the envelope yourself) so that size key would be insufficient. However, a sufficiently large RSA key to be correctly sized for 256 bit AES is totally impractical for performance reasons, see: http://www.nsa.gov/business/programs/elliptic_curve.shtml So clearly the purpose of pushing ECC for this application is that they want the public key algorithm and its key size to have comparable security while both performing reasonably well. (Same for DH and DSA.) It looks as if they are betting that factoring and discrete logs over the integers aren't as hard as people had thought. Not at all, and the rationale is public and seen above. I believe you're incorrectly claiming that we know much less than we actually do here. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Sep 1, 2013, at 10:35 PM, James A. Donald wrote: Meanwhile, on the authentication side, Stuxnet provided evidence that the secret community *does* have capabilities (to conduct a collision attacks) beyond those known to the public - capabilities sufficient to produce fake Windows updates. Do we know they produced fake windows updates without assistance from Microsoft? For some version of know. From http://arstechnica.com/security/2012/06/flame-malware-was-signed-by-rogue-microsoft-certificate/: Microsoft released an emergency Windows update on Sunday after revealing that one of its trusted digital signatures was being abused to certify the validity of the Flame malware that has infected computers in Iran and other Middle Eastern Countries. The compromise exploited weaknesses in Terminal Server, a service many enterprises use to provide remote access to end-user computers. By targeting an undisclosed encryption algorithm Microsoft used to issue licenses for the service, attackers were able to create rogue intermediate certificate authorities that contained the imprimatur of Microsoft's own root authority certificate—an extremely sensitive cryptographic seal. Rogue intermediate certificate authorities that contained the stamp were then able to trick administrators and end users into trusting various Flame components by falsely certifying they were produced by Microsoft Based on the language in Microsoft's blog posts, it's impossible to rule out the possibility that at least one of the certificates revoked in the update was ... created using [previously reported] MD5 weaknesses [which allowed collision attacks]. Indeed, two of the underlying credentials used MD5, while the third used the more advanced SHA-1 algorithm. In a Frequently Asked Questions section of Microsoft Security Advisory (2718704), Microsoft's security team also said: During our investigation, a third Certificate Authority has been found to have issued certificates with weak ciphers. The advisory didn't elaborate. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Mon, 2 Sep 2013 19:53:03 +0200 Faré fah...@gmail.com wrote: On Mon, Sep 2, 2013 at 7:19 PM, Perry E. Metzger pe...@piermont.com wrote: On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote: At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. I don't understand why. The security requirement is that third parties must *not* be able to predict the token, because then they could sign the token without controlling the email address. The only organization that can know the cookie is actually the organization sending the cookie out. You appear to have inverted the security requirement... In my scheme, no one can predict it, everyone can postdict it, *after* the trusted organization published its salt, at which point it's too late to send it signed confirmations. Therefore, neither side can cheat. I don't see what threat this averts. If the sending organization is cheating, this does not stop them from pretending that they received a signed cookie in a round trip. It just seems to add complexity. The only interesting form of cheating I can think of is pretending a round trip existed when it did not. In particular, the trusted organization has precious little power to extract information by handing users carefully crafted cookies. I don't see how that is an issue either, unless you are referring to chosen plaintext attacks, but the encryption format had better already defend against those. For even less power, the organization can publish digests of its salts years in advance. Again, I don't understand the threat being defended against. Can you articulate exactly what was possible before that is not possible in the scheme you propose? Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Mon, Sep 2, 2013 at 7:19 PM, Perry E. Metzger pe...@piermont.com wrote: On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote: At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. I don't understand why. The security requirement is that third parties must *not* be able to predict the token, because then they could sign the token without controlling the email address. The only organization that can know the cookie is actually the organization sending the cookie out. You appear to have inverted the security requirement... In my scheme, no one can predict it, everyone can postdict it, *after* the trusted organization published its salt, at which point it's too late to send it signed confirmations. Therefore, neither side can cheat. In particular, the trusted organization has precious little power to extract information by handing users carefully crafted cookies. For even less power, the organization can publish digests of its salts years in advance. Then, each user can just broadcast his signature of the previously unpredictable consensual data, and various timestamping organizations can sign messages that say yes, I saw that at this time, maybe charging some tiny usage fee in the process. But then *anyone* could broadcast the token because anyone could have predicted it. You can't broadcast the signed token unless you have the user's key. And sure, you can claim that you saw the signed token before the deadline, but unless you got a tree the hash of which was published as an ad in a reputable print institution, what value has your word? It is difficult to make the interchange of the token and the reply itself widely witnessed -- the way around that is to have many So, to cheat, you need both the user's key and the trusted organization's complicity. Or to have broken the digest, of course. organizations doing the interchanges so that one would have to suborn all of them. Interchange is expensive. Hopefully, you only need to reply to a handful of them every so many months. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but That's funny ... — Isaac Asimov ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
recent post with email discussing PGP-like implementation ... a decade before PGP in financial crypto blog http://www.garlic.com/~lynn/2013i.html#69 and then a little later realizing there were 3-kinds of crypto (when I was told I could make as many boxes as I wanted ... but could only sell to a certain gov. agency). In the late 90s, I worked on crypto chip for financial applications ... I would facetiously talk about taking a $500 mil-spec chip and cost reduce by 2-3 orders of magnitude while making it more secure (final objective was well under a dollar). Part of the objective was also to eliminate all the vulnerabilities that payment chips being done primarily in Europe were prone too. Long winded thread in financial crypto blog http://www.garlic.com/~lynn/subintegrity.html#yescard About that time, I was also approached by the transit industry to make the payment chip meet transit turnstyle requirements (while not reducing any security) ... this was a contactless chip being able to do crypto operation in 1/10th sec elapsed time and power profile of contactless transit turnstyle operation. RSA chips at the time were really large implementing 1024-bit arithmatic requiring enormous power and contact operation to get time in a few seconds. It turns out I could have a AADS chip strawman with ECC that was higher integrity *AND* could meet the transit industry turnstyle contactless power elapsed time profile. some past references to AADS chip strawman http://www.garlic.com/~lynn/x959.html#aadsstraw I was also asked to give presentation at Intel trusted computing ... gone 404 but lives on at wayback machine http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13 one of the problems in the early part of the century was that I wanted to go for higher than EAL4+ evaluation ... but NIST(somebody) pullled the ECC evaluation criteria ... and since ECC was part of the chip silicon ... w/o the ECC evaluation criteria ... I had to settle for EAL4+. Possibly part of the issue with AADS chip strawman was I approached it as purely a cost issue ... and the objective was to eliminate all possible costs from the whole infrastructure ... the side effect of course, it also eliminated all related profit. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Mon, 2 Sep 2013 15:09:31 -0400 Jerry Leichter leich...@lrw.com wrote: On Sep 2, 2013, at 1:25 PM, Perry E. Metzger wrote: On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com wrote: - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. That is a misunderstanding. If you look at the way that the NSA specs these things, they try to keep all portions of a system of equal security so none is the weak point. A 2048 bit RSA key is factored vastly more easily than a 256 bit AES key is brute forced (that's just public knowledge -- try doing the back of the envelope yourself) so that size key would be insufficient. However, a sufficiently large RSA key to be correctly sized for 256 bit AES is totally impractical for performance reasons, see: http://www.nsa.gov/business/programs/elliptic_curve.shtml a) The very reference you give says that to be equivalent to 128 bits symmetric, you'd need a 3072 bit RSA key - but they require a 2048 bit key. Only as a legacy you can do this for a while but please switch. And the same reference says that to be equivalent to 256 bits symmetric, you need a 521 bit ECC key - and yet they recommend 384 bits. So, no, even by that page, they are not recommending equivalent key sizes - and in fact the page says just that. I'd say they're judging a balance between security and performance while attempting not to leave particularly bad holes. b) Those comparisons long ago became essentially meaningless. On the symmetric size, it's using brute force attack strengths. But no one is going to brute force a 128-bit key with any known or suggested technology, and brute force attacks against 256-bit keys are way beyond what physics says is even remotely possible. I believe that is indeed a factor here, and is probably part of why the asymmetric key lengths aren't a bit longer. It is also possible they've been selected based on knowledge that AES keys are slightly weaker than we expect, but not radically so. As an aside, I'm reminded of the fact that there were certificational weaknesses in Skipjack that meant it was only more or less as potentially secure as the number of bits available in they key length. When this was pointed out to someone in the know, the mumble back I remember was in other words, they did the engineering correctly. Anyway, as I've said, I'm paranoid, but I operate under the assumption the counterparty is a reasonably rational actor that understands the very limited duration of secrets. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Sep 2, 2013, at 1:25 PM, Perry E. Metzger wrote: On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com wrote: - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. That is a misunderstanding. If you look at the way that the NSA specs these things, they try to keep all portions of a system of equal security so none is the weak point. A 2048 bit RSA key is factored vastly more easily than a 256 bit AES key is brute forced (that's just public knowledge -- try doing the back of the envelope yourself) so that size key would be insufficient. However, a sufficiently large RSA key to be correctly sized for 256 bit AES is totally impractical for performance reasons, see: http://www.nsa.gov/business/programs/elliptic_curve.shtml a) The very reference you give says that to be equivalent to 128 bits symmetric, you'd need a 3072 bit RSA key - but they require a 2048 bit key. And the same reference says that to be equivalent to 256 bits symmetric, you need a 521 bit ECC key - and yet they recommend 384 bits. So, no, even by that page, they are not recommending equivalent key sizes - and in fact the page says just that. b) Those comparisons long ago became essentially meaningless. On the symmetric size, it's using brute force attack strengths. But no one is going to brute force a 128-bit key with any known or suggested technology, and brute force attacks against 256-bit keys are way beyond what physics says is even remotely possible. (I posted on this a long time back: Any theory even vaguely consistent with what we know about quantum mechanics places a limit on the number of elementary bit flips in a finite volume of space-time. If you want an answer in 100 years, your computer is at most a sphere in space-time 100 light-years cubed by 100 years in diameter - and that's a gross overestimate. My quick calculation showed that the quantum limit for that sphere is not far above 128 bits.) In any real terms, *if you're talking brute force*, 128 bits and 256 bits - and a million bits, if you want to go nuts about it - are indistinguishable. For the other columns, they don't say where the difficulty estimate comes from. (You could get a meaningless estimate by requiring that the number of primes of the size quoted be equivalent to the number of symmetric keys, but I'm assuming they're being more intelligent about the estimate than that, as a brute force attack on primes makes no sense at all. What makes more sense - and what they are presumably using - is the number of operations needed by the best known algorithm. But now we're at point of comparing impossible attacks against 128- and 256-bit symmetric keys with impossible attacks against 3072- or 15360-bit RSA keys - a waste of time. The relevant point is that attacks against RSA keys have been getting better faster than predicted, while the best publicly known attacks against AES have barely moved the needle from simple brute force. Given *currently publicly known algorithms*, a 2048 bit RSA key is still secure. (The same page shows that as equivalent to a 112-bit symmetric key, which is not only beyond any reasonable-term brute force attack, but longer than the keys used - according to some reports, anyway - on some Suite A algorithms.) So clearly the purpose of pushing ECC for this application is that they want the public key algorithm and its key size to have comparable security while both performing reasonably well. (Same for DH and DSA.) It looks as if they are betting that factoring and discrete logs over the integers aren't as hard as people had thought. And here we actually agree. Note that I didn't say there was any evidence that NSA was ahead of the public state of the art - even given the public state of the art and the rate that it's advancing, using Z/p as a field is rapidly fading as a realistic alternative. NSA, looking forward, would be making the recommendation to move to elliptic curves whether or not they could do better than the public at large. So we can't read much into that aspect of it. However, note (a) that if NSA does have a theoretical breakthrough, factoring is probably more likely than AES - we know they've hired many people in related fields over many years, and even in public the state of the art has been advancing; (b) most of the Internet is way behind recommendations that are now out there for everyone. Google recently switched to 2048 bit keys; hardly any other sites have done so, and some older software even has trouble talking to Google as a result. Not at all, and the rationale is public and seen above. I believe you're incorrectly claiming that we know much less than we
Re: [Cryptography] NSA and cryptanalysis
On Sun, Sep 1, 2013 at 10:35 PM, James A. Donald jam...@echeque.com wrote: On 2013-09-01 9:11 PM, Jerry Leichter wrote: Meanwhile, on the authentication side, Stuxnet provided evidence that the secret community *does* have capabilities (to conduct a collision attacks) beyond those known to the public - capabilities sufficient to produce fake Windows updates. Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Mon, 2 Sep 2013 14:45:00 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. But of course, sufficiently paranoid people might contend that perhaps the Microsoft people who complained might not have been briefed by the ones who cooperated. The problem with all such exercises is that they involve too many layers of recursive paranoia, but do not pay off with useful information that tells me how to act going forward. In the current case, the fact that they *could* potentially suborn process inside a vendor is an interesting thing to consider when doing design, and whether they *have* is less interesting to me. Clearly, as things like bad vendor drivers updates have been sent out using stolen keys in the past, and clearly vendors might simply make mistakes in the future. From there, I can consider whether the someone at vendor signs bad updates security model component is productive to defend against or not, and how one might defend against it. (In the current case, I'd say only typed assembly language offers an interesting defense against bad binaries that get executed in kernel mode, regardless of why they are bad. Using typed assembly language effectively of course requires that the code be written in a high level language with strong typing to be preserved in the delivered machine code in the first place.) I leave speculation to pundits, and prefer to write code and design protocols. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
You know, if there was a completely ironclad legal opinion that made use of ECC possible without the risk of a lawsuit costing over $2 million from Certicom then I would be happy to endorse a switch to ECC like the NSA is pushing for as well. I would not therefore draw the conclusion that NSA advice to move to ECC is motivated by knowledge of a crack of RSA, if anything that would argue against moving from ECC. It is merely a consequence of the US government having a license which we don't have. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. But of course, sufficiently paranoid people might contend that perhaps the Microsoft people who complained might not have been briefed by the ones who cooperated. I would be very surprised if they had gotten any assistance from Microsoft. It goes against the grain. Microsoft engineers are really indoctrinated with the trustworthy computing agenda, with mandatory security training every year, specialized design reviews, code reviews, tests and all that. Not saying there are no bugs or oversights in Microsoft's code, but a deliberate action like that is very unlikely. Also, It would be very difficult to keep something like that secret for long, and the leak would have dire effects on the company's reputation. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Mon, 2 Sep 2013 13:14:00 -0700 Christian Huitema huit...@huitema.net wrote: Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. But of course, sufficiently paranoid people might contend that perhaps the Microsoft people who complained might not have been briefed by the ones who cooperated. I would be very surprised if they had gotten any assistance from Microsoft. As would I. Not my wider point. My wider point is that the speculation is not helpful, and one probably wants to think about how to make things trustworthy even in the presence of bugs, adversaries who look like bugs for most viewpoints, etc. Paranoid speculation is useless, concrete discussion of threat models and how to address them is useful. (Thus why I mentioned things like typed assembly language as being a more productive topic than infinitely recursive paranoia. One can speculate endlessly on who is collaborating with whom without ever terminating, but robust threat models with technical solutions are something you can actually do something about.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Mon, 2 Sep 2013 17:44:57 -0400 Jerry Leichter leich...@lrw.com wrote: ...Clearly, as things like bad vendor drivers updates have been sent out using stolen keys in the past, and clearly vendors might simply make mistakes in the future Except that that's not what happened in this case. Someone took an old, valid Microsoft license - which should never Yes, certainly, but the end effect was that an untrustworthy piece of code was then executing on the victim's machine. That can be happen by many means, however, both intentional and accidental -- trojan horses, vendor mistakes, bugs, rogue employees at a vendor, a vendor's credentials being stolen, cryptographic breaks like this, etc. Now, I do indeed find it interesting and exotic that someone involved knows how to create MD5 collisions by a different method than we know of in the open literature, and that tickles my fancy as a person who loves cryptography, and probably tells us something about who wrote that particular exploit. What it does not do, however, is tell me much about how to make systems robust against the wide variety of reasons why untrustworthy software might appear on a machine. As a security person, it is this latter problem that is vital to me, since doubtless that will show up again in the future. Even ignoring malice, bugs often happen in device drivers and other code running in security critical environments like kernels. I will again mumble things like: typed assembly language, proof carrying code, microkernels, hardware assists, formal verification... in the hopes that the mumbling might set some minds thinking. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. ...Clearly, as things like bad vendor drivers updates have been sent out using stolen keys in the past, and clearly vendors might simply make mistakes in the future Except that that's not what happened in this case. Someone took an old, valid Microsoft license - which should never have been issued, and which was blocked on Vista and Windows 7. They worked around the block using a technique that required the ability to produce MD5 collisions, which allowed them to spoof Windows Update. All the details are at http://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf. A cryptographic approach for producing chosen-prefix collisions in MD5 was presented at CCC in 2008, with a cost estimate of about $20K on a 2008 Amazon EC2 cluster - the authors showed a POC using a cluster of PS3's. Open source code to implement the attack was published in 2009. However, the form of the collision apparently didn't match the published code, nor, more fundamentally, the theoretical work that made it possible. Someone has a *different*, so far nowhere-published attack. The comment that this required world-class cryptanalysis came from the developer of the published chosen-prefix attack, Marc Stevens. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Google's Public Key Size (was Re: NSA and cryptanalysis)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Sep 02, 2013 at 03:09:31PM -0400, Jerry Leichter wrote: Google recently switched to 2048 bit keys; hardly any other sites have done so, and some older software even has trouble talking to Google as a result. Btw. As a random side-note. Google switched to 2048 bit RSA keys on their search engine. However my connection to mail.google.com is using a NIST p256r1 ECC key in its certificate. - -Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSJQt78CBzV/QUlSsRAtO0AKDkltH4HUVw5Pa2lwCLhHLAGrIJHACgxzZh 1EInnyyRoKX4xZ1rQ0M9c2g= =uOUn -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Mon, Sep 02, 2013 at 03:09:31PM -0400, Jerry Leichter wrote: a) The very reference you give says that to be equivalent to 128 bits symmetric, you'd need a 3072 bit RSA key - but they require a 2048 bit key. And the same reference says that to be equivalent to 256 bits symmetric, you need a 521 bit ECC key - and yet they recommend 384 bits. So, no, even by that page, they are not recommending equivalent key sizes - and in fact the page says just that. Suite B is specified for 128 and 192 bit security levels, with the 192 bit level using ECC-384, SHA-384, and AES-256. So it seems like if there is a hint to be drawn from the Suite B params, it's about AES-192. (b) most of the Internet is way behind recommendations that are now out there for everyone. Google recently switched to 2048 bit keys; hardly any other sites have done so, and some older software even has trouble talking to Google as a result. Not to mention that our entire PKI system (as well as TLS 1.2, ie the versions actually supported in browsers) rely on the security of SHA-1, an algorithm which has a public 2**68 (IIRC) collision attack and which was phased out by NIST years ago. Fortunately now TLS 1.2 is finally being forced into most browsers thanks to BEAST, Lucky13, RC4 breaks, etc but still we're bound to see some major problems on the PKI side when a practical chosen prefix SHA-1 collision is found, as I expect at least a few widely used CAs have still not adopted randomized serial numbers and will have the MD5 experience all over again. On the symmetric side, I've already agreed that NSA's approval indicated that the considered AES secure 10 years ago, but if they've since learned otherwise but think they are and will remain the only ones with a viable attack for a while, they would be unlikely to admit it by changing their recommendation now. Worth noting that NIST has announced plans to create AEAD modes based on Keccak. It will be interesting to see how quickly AES-GCM is phased out of Suite B once that occurs. Jack ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Backup is completely separate
The backup access problem isn't just a crypto problem, it's a social/legal problem. There ultimately needs to be some outside mechanism for using social or legal means to ensure that, say, my kids can get access to at least some of my encrypted files after I drop dead or land in the hospital in a coma. Or that I can somehow convince someone that it's really me and I'd like access to the safe deposit box whose password I forgot and lost my backup copy of. Or whatever. This is complicated by the certainty that if someone has the power to get access to my encrypted data, they will inevitably be forced to do so by courts or national security letters, and will also be subject to extralegal pressures or attacks to make them turn over some keys. I suspect the best that can be workably done now is to make any key escrow service's key accesses transparent and impossible to hide from the owner of the key, and then let users decide what should and shoudn't be escrowed. But this isn't all that great an answer. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 2, 2013, at 3:06 PM, Jack Lloyd ll...@randombit.net wrote: On Mon, Sep 02, 2013 at 03:09:31PM -0400, Jerry Leichter wrote: a) The very reference you give says that to be equivalent to 128 bits symmetric, you'd need a 3072 bit RSA key - but they require a 2048 bit key. And the same reference says that to be equivalent to 256 bits symmetric, you need a 521 bit ECC key - and yet they recommend 384 bits. So, no, even by that page, they are not recommending equivalent key sizes - and in fact the page says just that. Suite B is specified for 128 and 192 bit security levels, with the 192 bit level using ECC-384, SHA-384, and AES-256. So it seems like if there is a hint to be drawn from the Suite B params, it's about AES-192. The real issue is that the P-521 curve has IP against it, so if you want to use freely usable curves, you're stuck with P-256 and P-384 until some more patents expire. That's more of it than 192 bit security. We can hold our noses and use P-384 and AES-256 for a while. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSJWpasTedWZOD3gYRAjMtAKD/W9IPWtI8qwpP7w0v1aX9BgrwHACeMsRl 594r4LFPCTsIA9+xBUk4/5Q= =RGYR -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
