- cypherpunks@lists.ogf.org

Re: [tor-talk] NIST approved crypto in Tor?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Nick Mathewson <nickm(a)alum.mit.edu> ----- Date: Sat, 7 Sep 2013 13:02:04 -0400 From: Nick Mathewson <nickm(a)alum.mit.edu> To: "tor-talk(a)lists.torproject.org" <tor-talk(a)lists.torproject.org> Subject: Re: [tor-talk] NIST approved crypto in Tor? Reply-To: tor-talk(a)lists.torproject.org On Sat, Sep 7, 2013 at 5:25 AM, Sebastian G. <bastik.tor> <bastik.tor(a)googlemail.com> wrote: > Hi, > > Tor switches over to ECC what's a reasonable step. > > I'm unable to find the blog post (or maybe it was an official comment on > the blog) [With DDG and StartPage] where someone said that if the NIST > (I guess) is not lying ECC is safe. > > Is the ECC used by Tor in some way certified by NIST? The TLS ECDH groups P-256 and P-224 are NIST-certified. For circuit extension, we use Dan Bernstein's non-NIST-certified curve25519 group. > Are other parts of Tor certified by NIST? NIST has certified tons of stuff, including AES and SHA1 and SHA256 and SHA3. If you're jumping ship from NIST, you need to jump ship from those as well. Of all the NIST stuff above, my suspicion is not that they are cryptographically broken, but that they are deliberately hard to implement correctly: see * http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf (on the P groups) and * http://cr.yp.to/antiforgery/cachetiming-20050414.pdf (on AES) Also, we're not using DSA, but DSA (as recommended by NIST) fits into this pattern: DSA (as recommended by NIST) requires a strong random number generator to be used when signing, and fails terribly in a way that exposes the private key if the random number generator is the least bit week or predictable. (see https://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity) To me, this suggests a trend of certifying strong cryptographic algorithms while at the same time ensuring that most implementations will be of poor quality. That's just speculation, though. (And I'm probably falling to the fallacy where you assume that whatever results somebody gets are the ones they wanted.) Of course, the "deliberately" in "deliberately hard to implement correctly" is almost impossible to prove. Is it nearly impossible to write a fast side-channel-free AES implemenation in C because because of a nefarious conspiracy, or simply because cryptographers in 2000 didn't appreciate how multiplication in GF(2^8) wasn't as software-friendly a primitive? (Looking at the other AES finalists, I see a bunch of other hard-to-do-right-in-fast-software stuff like GF(2^8) multiplication and table-based s-boxes.) Are the ECC P groups shaped that way for nefarious reasons, or simply because the standards committee didn't have an adequate appreciation of the software issues? And it's not like NIST standards are the only ones that have problems. TLS is an IETF standard, but TLS implementations today have three basic kinds of ciphersuirte: a fraught-with-peril CBC-based pad-MAC-then-encrypt kind where somebody finds a new active attack every year or so; a stream-cipher-based kind where the only supported stream cipher is the ridiculously bad RC4, and an authenticated encryption kind where the the AEAD mode uses GCM, which is also hard to do in a side-channel-free way in software. Conspiracy, or saboteurs in the (international) TLS working group, or international bureaucratic intertia? Who can say? And let's not mention X.509. Let's just not, okay? X.509 is byzantine in a way that would make any reasonable implementor's head spin, *and* the X.509 CA infrastructure is without a doubt one of the very worst things in web security today. And it's an international standard. [...] > I understand that ECC used for Tor is different from what the essay is > about. > > However the NSA may found something it can exploit in ECC and made NIST > (maybe unknowingly) standardize the curve (or whatever) that is most > vulnerable or recommends for a weak one, or for too short keys. > > Does Tor use stuff certified or recommended by NIST? Yes; see above. Also, there were once NIST recommendations for using TLS; I have no idea whether we're following them or not. (There are NIST recommendations for nearly ) > If so would it be reasonable to move to international standards > (whatsoever) without the involvement of NIST and NSA 'consultation'? > (Completely unrelated to what might be going on, just as defense-in-depth.) I'm not sure that there *are* international-standards recommendations for ECC groups or for ciphers that diverge from NIST's. The IETF is an international body, after all, and TLS standards have been happily recommending SHA1, SHA256, AES, DSA, and the P groups for ages. (See also notes above about the not-much-betterness of international stuff.) With any luck, smart cryptographers will start to push non-NIST curves and ciphers into prominence. I've got some hopes for the EU here; ECRYPT and ECRYPT II produced some exceptionally worthwhile results; I hope that whoever makes funding decisions funds a nice targeted ECRYPT III some time. As I said on another mail, I've got a mind to move a lot of our crypto for other reasons, as well. The elephant in the room here is TLS itself. Frankly, I'm starting to think we should cut the Gordian Knot here and start a little independent protocol group of our own if the TLS working group can't get its act together and have one really good ciphersuite some time soon. > The NSA likes playing around. [2][3] (found while searching) > > Oh and I'm not trying fear-mongering here or try to conspire whenever or > not the NSA has subverted cryptographic functions (in one way or another). Yeah, I know how it is. I'm seeing conspiracies under every protocol and in every patch these days. Gotta stay focused, write the best protocols and designs and software I can, and maintain. (And with that in mind I should really start on my weekend soon.) peace, -- Nick -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [tor-talk] NSA has cracked web encryption!
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from krishna e bera <keb(a)cyblings.on.ca> ----- Date: Sat, 07 Sep 2013 12:02:06 -0400 From: krishna e bera <keb(a)cyblings.on.ca> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] NSA has cracked web encryption! User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 Reply-To: tor-talk(a)lists.torproject.org On 13-09-06 10:26 PM, Nick Mathewson wrote: > Over the 0.2.5 series, I want to move even more things (including > hidden services) to curve25519 and its allies for public key crypto. > I also want to add more hard-to-implement-wrong protocols to our mix: > Salsa20 is looking like a much better choice to me than AES nowadays, > for instance. I also want to support more backup entropy sources. Schneier says in the Guardian [1]: "Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can." and in Wired [2]: " Breakthroughs in factoring have occurred regularly over the past several decades, allowing us to break ever-larger public keys. Much of the public-key cryptography we use today involves elliptic curves, something that is even more ripe for mathematical breakthroughs. It is not unreasonable to assume that the NSA has some techniques in this area that we in the academic world do not. Certainly the fact that the NSA is pushing elliptic-curve cryptography is some indication that it can break them more easily. If we think that’s the case, the fix is easy: increase the key lengths. The NSA can make use of everything discovered and openly published by the academic world, as well as everything discovered by it in secret. Assuming the hypothetical NSA breakthroughs don’t totally break public-cryptography — and that’s a very reasonable assumption — it’s pretty easy to stay a few steps ahead of the NSA by using ever-longer keys. We’re already trying to phase out 1024-bit RSA keys in favor of 2048-bit keys. Perhaps we need to jump even further ahead and consider 3072-bit keys. And maybe we should be even more paranoid about elliptic curves and use key lengths above 500 bits. " Are there some assurances that Tor is using the best parameters on its symmetric, public key and curve cryptography? And how can we check? [1] http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surve… [2] http://www.wired.com/opinion/2013/09/black-budget-what-exactly-are-the-nsas… -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [liberationtech] Random number generation being influenced - rumors
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Andy Isaacson <adi(a)hexapodia.org> ----- Date: Fri, 6 Sep 2013 22:24:00 -0700 From: Andy Isaacson <adi(a)hexapodia.org> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Random number generation being influenced - rumors User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote: > On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson <adi(a)hexapodia.org> wrote: > > This is not to say that RdRand is completely unusable. Putting RdRand > > entropy into a software pool implementation like /dev/urandom (or > > preferably, a higher-assurance multipool design like Fortuna) is a cheap > > way to prevent a putative backdoor from compromising your system state. > > Nearly nothing from what you wrote is relevant to RDRAND, which is not > a pure HWRNG, but implements CTR_DRBG with AES (unclear whether > 128/192/256) from NIST SP 800-90A [1,2]. That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input. Providing accessible "test points" (software interfaces to the innards of the implementation, with documentation of expected behavior between the components) would be the absolute minimum to provide believable assurance of the absence of a backdoor. Better would be documents from Intel of how the chip is designed at the mask level, and a third party mill-and-microphotograph of a retail chip showing that the shipped implementation matches the design. Intel will never go for that, of course, since their chip masks are their jealously guarded IP. Since they can't provide evidence of a lack of a backdoor, any reasonably cautious user should avoid depending on Intel's implementation. -andy -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from "Marcus D. Leech" <mleech(a)ripnet.com> ----- Date: Fri, 06 Sep 2013 23:51:49 -0400 From: "Marcus D. Leech" <mleech(a)ripnet.com> To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] Why prefer symmetric crypto over public key crypto? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 > > The magic of public key crypto is that it gets rid of the key > management problem -- if I'm going to communicate with you with > symmetric crypto, how do I get the keys to you? The pain of it is > that it replaces it with a new set of problems. Those problems > include that the amazing power of public-key crypto tempts one to > do things that may not be wise. > I find public-key cryptography to be full of "dirty little secrets". Some of the notions inherent in public-key *infrastructure* are, on the face of them, preposterous. Consider the notion of a certificate authority. I am to trust some third party (the CA) that I've never met, and have not the slightest reason to trust, is able to make a "believable" assertion about the identity (and corresponding public-key binding), of some *other* party I've never met, and have no real reason to trust. It always struck me as another instance of "there's no problem in CS that can't be solved by adding another layer of abstraction". I think this is an instance of a general problem with digitally-signed documents of all kinds: confusion about exactly what they are--a signature on a document (like a certificate) says nothing about the *essential truth* of the statements contained within the document. When SlushySign issues a certificate for "www.crowbars-r-us.com", there's a subtle distinction between "we believe this to be the appropriate binding between this public-key, and an entitity known as www.crowbars-r-us.com" and "this really is the binding between this pubic-key, and the entity you all know as www.crowbars-r-us.com". I started thinking about the "essential truth" problem back when the whole TPM thing was popular, and proponents were talking as if the digital signature of a computer stating that it was "sane" was somehow the same is said computer actually being "sane". Absent independent verification, there's no way to distinguish a strongly-signed "lie" from a strongly-signed "truth". That isn't necessarily a problem that's confined to PK systems. Any digital-signature scheme has that problem. The other thing that I find to be a "dirty little secret" in PK systems is revocation. OCSP makes things, in some ways, "better" than CRLs, but I still find them to be a kind of "swept under the rug" problem when people are waxing enthusiastic about PK systems. However, PK is the only pony we've managed to bring to this circus, so, we we "make do" with making the "dirty little secrets" as inoffensive as we can. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] NSA hates sunshine
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Fri, 06 Sep 2013 19:13:17 -0700 From: John Gilmore <gnu(a)toad.com> To: Paul Hoffman <paul.hoffman(a)vpnc.org> Cc: Andy Steingruebl <steingra(a)gmail.com>, "cryptography(a)metzdowd.com List" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] NSA hates sunshine > > As of Jan-2014 CAs are forbidden from issuing/signing anything less than 2048 certs. > > For some value of "forbidden". :-) Yeah, just like employees at big companies are "forbidden" to reveal how they are collaborating with NSA. Years ago I heard what happened when George Davida filed a patent on something related to encryption, all the way back in 1978, and eventually received a communication from the government telling him that his patent was subject to patent secrecy, that it would never issue, and that he could not even tell anyone that it had been suppressed, nor could he ever tell anyone how his invention worked. In theory, the law was all on the NSA's and the patent office's side. But in fact, they were in a very weak position. Instead of acquiescing, Davida shouted it to the housetops, engaged the press and his university about censorship of academic freedom, involved his Congressperson, etc. Within months, the secrecy order was rescinded. NSA hates sunshine. NSA secrecy relies on the cowardice of most people. Courage is all it takes to beat them. If NSA tries to shut you up, just shine a lot of attention on their attempt to shut you up. Spread the information that they are trying to suppress, far and wide. Send copies to a dozen random post-office boxes in different cities, asking the recipient to physically bring it in to their local newspaper. Leave your cellphone at home, then stash copies in places that you don't frequent, so that government agents can't come raid your house and office and steal all copies of what they're trying to suppress. In my case I posted something like this (a suppressed paper by Ralph Merkle) to Usenet, and it was suddenly on thousands of servers overnight. NSA habitually decides that the publicity that their activities get from any continued effort to suppress the information is FAR worse than the damage caused by the initial release of the info. Any efforts they make to shut you up, prosecute you, jail you, etc give you a perfect soapbox, and the attention of the news media and the public. Keep repeating the info, from your jail cell if necessary, and you're likely to win. Because if NSA relents, your revelations become "last week's news" and get a lot less public attention. When NSA found out I had copies of an early encryption tutorial that they considered classified (I was suing them under FOIA to get a copy, but then found copies in a public library), they first tried to persuade my lawyer to "bring in all the copies so we can secure them in a safe place". That's NSA-ese for "throw them down a deep hole where you'll never see them again". When we refused, and instead contacted the New York Times, which printed a story about the attempted suppression, NSA and DoJ buckled within one day. (Indeed, the way I found out they had suddenly declassified the document is that they called the NYT reporter to tell him. They never did tell me; I got the news from the reporter.) As part of suing the government, the Al Haramain foundation accidentally received a government report making it clear that the government had illegally wiretapped their phone calls. They noticed this but it took the government 60 days to notice. Unfortunately, instead of making hundreds of copies of the document, and spreading them all over the world and to the press, they did what the government asked, and destroyed all their copies of the document. Once all copies of the document were gone, NSA went to the court and claimed first that the whole thing was a state secret and couldn't proceed, and then second that the group didn't have any standing to challenge the wiretaps in court because Al Haramain (now) had zero evidence that the taps had even occurred. The foundation and their lawyers have literally spent years of work recovering from that one mistake, and only the kind indulgence of a smarter than average judge enabled their lawsuit to survive at all. See this story by one of their lawyers: http://www.salon.com/2008/07/09/alharamain_lawsuit/ Don't make the same mistake when NSA, or their minions at the FBI or FISA or DoJ come to threaten YOU to suppress information that came to you through no fault of your own. John Gilmore _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tor-talk] NIST approved crypto in Tor?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> ----- Date: Sat, 07 Sep 2013 11:25:24 +0200 From: "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> To: tor-talk(a)lists.torproject.org Subject: [tor-talk] NIST approved crypto in Tor? User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: tor-talk(a)lists.torproject.org Hi, Tor switches over to ECC what's a reasonable step. I'm unable to find the blog post (or maybe it was an official comment on the blog) [With DDG and StartPage] where someone said that if the NIST (I guess) is not lying ECC is safe. Is the ECC used by Tor in some way certified by NIST? Are other parts of Tor certified by NIST? Recent leaks revealed that the NSA spends many resources in influencing standards to make their lives easier (or not too hard). NIST could be either participating or tricked into preferring standards that are weak in some regard. Note that I'm not saying that this is the case, but it could be. I was able (it was not a blog post, it was an essay) to find what Bruce Schneier wrote about the NSA preferring a weak random-number-generator. [1] Quotes [my comments, notes]: "The U.S. government released a new official standard for random-number generators this year [essay from 2007], and it will likely be followed by software and hardware developers around the world." "(...) the 130-page document contains four different approved techniques, called (...) "Deterministic Random Bit Generators." All four are based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves." " (...) one of those generators (...) Dual_EC_DRBG [elliptic], (...) three orders of magnitude slower than its peers." " It's in the standard only because it's been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute." "The math is complicated, but the general point is that the random numbers it produces have a small bias. [2006 knowledge]" "But today [2007] there's an even bigger stink brewing around Dual_EC_DRBG" (...) Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor." "There are a bunch of constants -- fixed numbers -- in the standard used to define the algorithm's elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from." " (...) these numbers have a relationship with a second, secret set of numbers (...). If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. (...) you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG." "The researchers don't know what the secret numbers are. (...) the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem." " (...) we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG [or not, we can't know]" Read the full essay which contains links to papers if you are interested. And the NSA work on standards repeatedly. "The NSA has always been intimately involved in U.S. cryptography standards -- it is, after all, expert in making and breaking secret codes." That's also what comes out of the Snowden leaks. I understand that ECC used for Tor is different from what the essay is about. However the NSA may found something it can exploit in ECC and made NIST (maybe unknowingly) standardize the curve (or whatever) that is most vulnerable or recommends for a weak one, or for too short keys. Does Tor use stuff certified or recommended by NIST? If so would it be reasonable to move to international standards (whatsoever) without the involvement of NIST and NSA 'consultation'? (Completely unrelated to what might be going on, just as defense-in-depth.) The NSA likes playing around. [2][3] (found while searching) Oh and I'm not trying fear-mongering here or try to conspire whenever or not the NSA has subverted cryptographic functions (in one way or another). Best, Sebastian G. [1] https://www.schneier.com/essay-198.html [2] https://www.schneier.com/blog/archives/2008/01/nsa_backdoors_i.html [3] https://www.schneier.com/blog/archives/2013/07/simon_and_speck.html -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Jon Callas <jon(a)callas.org> ----- Date: Fri, 6 Sep 2013 17:58:33 -0700 From: Jon Callas <jon(a)callas.org> To: Jerry Leichter <leichter(a)lrw.com> Cc: cryptography(a)metzdowd.com, Jon Callas <jon(a)callas.org>, "Perry E. Metzger" <perry(a)piermont.com> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" X-Mailer: Apple Mail (2.1508) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 6, 2013, at 6:23 AM, Jerry Leichter <leichter(a)lrw.com> wrote: > Is such an attack against AES *plausible*? I'd have to say no. But if you were on the stand as an expert witness and were asked under cross-examination "Is this *possible*?", I contend the only answer you could give is "I suppose so" (with tone and body language trying to signal to the jury that you're being forced to give an answer that's true but you don't in your gut believe it). I'd be happy to give a different answer, like -- almost certainly not. > > Could an encryption algorithm be explicitly designed to have properties like this? I don't know of any, but it seems possible. I've long suspected that NSA might want this kind of property for some of its own systems: In some cases, it completely controls key generation and distribution, so can make sure the system as fielded only uses "good" keys. If the algorithm leaks without the key generation tricks leaking, it's not just useless to whoever grabs onto it - it's positively hazardous. The gun that always blows up when the bad guy tries to shoot it.... We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. To me, it's like getting a cheap supply of gold and then deciding you'll make bullets out of it instead of lead. To riff on that analogy, it feels like you're suggesting that they would shoot themselves in the foot because they know that the bullet fragments will hurt their opponent. That's why I say almost certainly not. It suggests irrationality beyond my personal ken. It's something I classify colloquially as "too stupid to live." My assumptions about the NSA are that they're smart, clever, and practical. Conjectures about their behavior that deviate from any of those axes ring false to the degree that they deviate from that. My conjectures start with assuming they're at least as smart as me, and I start with "what would I do if I were them?" I think they're smart enough not to attack the strong points of the system, but the weak points. I think they're smart enough to prefer operating in stealth. Yeah, yeah, sure, if with those resources I stumbled into a fundamental mathematical advantage, I'd use it. But I would use it to maximize my gain, not to be gratuitously sneaky. The math we know about block ciphers suggests (not proves, suggests) that a back door in a cipher is impractical, because it would imply the holy grail of public key systems -- fast, secure, public key crypto. It suggests secure trapdoor functions that can be made out of very simple components. If I found one, it would be great, but I'd devote my resources to places where I technology is on my side. Those include network security and software security, along with traffic analysis. If I wanted to devote research resources, I'd be looking closely at language-theoretic security. I'd be paying close attention to the fantastic things that have come out of there. The stuff that Bangert, Bratus, Shapiro, and Smith did on turning an MMU into a Turing machine is where I'd devote research, as well as their related work on "weird machines." I apologize for repeating myself, but I'd fight the next war, not the last one. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKno7sTedWZOD3gYRAjMUAJ9qDQcQZVr/1580qZStlu/7fFgLIwCg2U5r WFth65Vi4GIDF1wu5oVukYs= =M/f+ -----END PGP SIGNATURE----- _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] Compositing Ciphers?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Natanael <natanael.l(a)gmail.com> ----- Date: Sat, 7 Sep 2013 02:53:22 +0200 From: Natanael <natanael.l(a)gmail.com> To: noloader(a)gmail.com Cc: Cryptography List <cryptography(a)randombit.net> Subject: Re: [cryptography] Compositing Ciphers? http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html Apparently it's called "cascade encryption" or "cascade encipherment", and the implementations are apparently called "robust combiners". And by the way, Truecrypt already lets you pick your chosen combo of AES and two other ciphers. I think you should worry about your PRNG and it's seed before you focus on AES. Your key should both have enough entropy and be secret. Is your PRNG backdoored already? And I'm guessing the cipher mode probably matters a bit more than the exact choice of algorithm. On Sat, Sep 7, 2013 at 2:27 AM, Jeffrey Walton <noloader(a)gmail.com> wrote: > Hi All, > > With all the talk of the NSA poisoning NIST, would it be wise to > composite ciphers? (NY Times, Guardian, Dr. Green's blog, et seq). > > I've been thinking about running a fast inner stream cipher (Salsa20 > without a MAC) and wrapping it in AES with an authenticated encryption > mode (or CBC mode with {HMAC|CMAC}). > > I'm aware of, for example, NSA's Fishbowl running IPSec at the network > layer (the "outer" encryption") and then SRTP and the application > level (the "inner" encryption). But I'd like to focus on hardening one > cipherstream at one level, and not cross OSI boundaries. > > I'm also aware of the NSA's lightweight block ciphers > (http://eprint.iacr.org/2013/404) I may have been born at night, but > it was not last night.... > > Has anyone studied the configuration and security properties of a > inner stream cipher with an outer block cipher? > > Jeff > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[cryptography] Compositing Ciphers?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Jeffrey Walton <noloader(a)gmail.com> ----- Date: Fri, 6 Sep 2013 20:27:47 -0400 From: Jeffrey Walton <noloader(a)gmail.com> To: Cryptography List <cryptography(a)randombit.net> Subject: [cryptography] Compositing Ciphers? Reply-To: noloader(a)gmail.com Hi All, With all the talk of the NSA poisoning NIST, would it be wise to composite ciphers? (NY Times, Guardian, Dr. Green's blog, et seq). I've been thinking about running a fast inner stream cipher (Salsa20 without a MAC) and wrapping it in AES with an authenticated encryption mode (or CBC mode with {HMAC|CMAC}). I'm aware of, for example, NSA's Fishbowl running IPSec at the network layer (the "outer" encryption") and then SRTP and the application level (the "inner" encryption). But I'd like to focus on hardening one cipherstream at one level, and not cross OSI boundaries. I'm also aware of the NSA's lightweight block ciphers (http://eprint.iacr.org/2013/404) I may have been born at night, but it was not last night.... Has anyone studied the configuration and security properties of a inner stream cipher with an outer block cipher? Jeff _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Fri, 06 Sep 2013 17:22:26 -0700 From: John Gilmore <gnu(a)toad.com> To: Cryptography <cryptography(a)metzdowd.com>, gnu(a)toad.com Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" Speaking as someone who followed the IPSEC IETF standards committee pretty closely, while leading a group that tried to implement it and make so usable that it would be used by default throughout the Internet, I noticed some things: * NSA employees participted throughout, and occupied leadership roles in the committee and among the editors of the documents * Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied. * The resulting standard was incredibly complicated -- so complex that every real cryptographer who tried to analyze it threw up their hands and said, "We can't even begin to evaluate its security unless you simplify it radically". See for example: https://www.schneier.com/paper-ipsec.html That simplification never happened. The IPSEC standards also mandated support for the "null" encryption option (plaintext hiding in supposedly-encrypted packets), for 56-bit Single DES, and for the use of a 768-bit Diffie-Hellman group, all of which are insecure and each of which renders the protocol subject to downgrade attacks. * The protocol had major deployment problems, largely resulting from changing the maximum segment size that could be passed through an IPSEC tunnel between end-nodes that did not know anything about IPSEC. This made it unusable as a "drop-in" privacy improvement. * Our team (FreeS/WAN) built the Linux implementation of IPSEC, but at least while I was involved in it, the packet processing code never became a default part of the Linux kernel, because of bullheadedness in the maintainer who managed that part of the kernel. Instead he built a half-baked implementation that never worked. I have no idea whether that bullheadedness was natural, or was enhanced or inspired by NSA or its stooges. In other circumstances I also found situations where NSA employees explicitly lied to standards committees, such as that for cellphone encryption, telling them that if they merely debated an actually-secure protocol, they would be violating the export control laws unless they excluded all foreigners from the room (in an international standards committee!). The resulting paralysis is how we ended up with encryption designed by a clueless Motorola employee -- and kept secret for years, again due to bad NSA export control advice, in order to hide its obvious flaws -- that basically XOR'd each voice packet with the same bit string! Their "encryption" scheme for the control channel, CMEA, was almost as bad, being breakable with 2^24 effort and small numbers of ciphertexts: https://www.schneier.com/cmea-press.html To this day, no mobile telephone standards committee has considered or adopted any end-to-end (phone-to-phone) privacy protocols. This is because the big companies involved, huge telcos, are all in bed with NSA to make damn sure that working end-to-end encryption never becomes the default on mobile phones. John Gilmore _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0