- cypherpunks - lists.cpunks.org

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

08 Sep '13

----- Forwarded message from "Jeffrey I. Schiller" <jis(a)mit.edu> ----- Date: Sat, 7 Sep 2013 10:05:22 -0400 From: "Jeffrey I. Schiller" <jis(a)mit.edu> To: ianG <iang(a)iang.org> Cc: cryptography(a)metzdowd.com Subject: Re: [Cryptography] Why prefer symmetric crypto over public key crypto? User-Agent: Mutt/1.5.21 (2010-09-15) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Sep 07, 2013 at 10:57:07AM +0300, ianG wrote: > It's a big picture thing. At the end of the day, symmetric crypto > is something that good software engineers can master, and relatively > well, in a black box sense. Public key crypto not so easily, that > requires real learning. I for one am terrified of it. Don’t be. There is no magic there. From what I can tell, there are two different issues with public key. 1. Weaknesses in the math. 2. Fragility in use. The NSA (or other national actors) may well have found a mathematical weakness in any of the public key ciphers (frankly they may have found a weakness in symmetric ciphers as well). Frankly, we just don’t know here. Do we trust RSA more then Diffie-Hellman or any of the Elliptic Curve techniques? Who knows. We can make our keys bigger and hope for the best. As for fragility. Generating random numbers is *hard*, particularly on a day to day basis. When you generate a keypair with GPG/PGP it prompts you to type in random keystrokes and move the mouse etc., all in an attempt to gather as much entropy as possible. This is a pain, but it makes sense for one-lived keys. People would not put up with this if you had to do this for each session key. Fragile public key systems (such as Elgamal and all of the variants of DSA) require randomness at signature time. The consequence for failure is catastrophic. Most systems need session keys, but the consequence for failure in session key generation is the compromise of the message. The consequence for failure in signature generation in a fragile public key system is compromise of the long term key! I wrote about this in NDSS 1991.... I cannot find an on-line reference to it though. Then if you are a software developer, you have the harder problem of not being able to control the environment your software will run on, particularly as it applies to the availability of entropy. So my advice. Use RSA, choose a key as long as your paranoia. Like all systems, you will need entropy to generate keys, but you won’t need entropy to use it for encryption or for signatures. - -Jeff _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room E17-110A, 32-392 Cambridge, MA 02139-4307 617.910.0259 - Voice jis(a)mit.edu http://jis.qyv.name _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSKzKi8CBzV/QUlSsRAhoSAJ98g7NreJwIK+aYODM1zDsVsreMCQCcD2R9 vnvmNc4Uo45+ckUFQafuE4U= =x9bK -----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] XORing plaintext with ciphertext
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Jerry Leichter <leichter(a)lrw.com> ----- Date: Sat, 7 Sep 2013 07:25:43 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: Jon Callas <jon(a)callas.org> Cc: Cryptography List <cryptography(a)metzdowd.com>, Dave Horsfall <dave(a)horsfall.org> Subject: Re: [Cryptography] XORing plaintext with ciphertext X-Mailer: Apple Mail (2.1283) On Sep 7, 2013, at 4:13 AM, Jon Callas wrote: >> Take the plaintext and the ciphertext, and XOR them together. Does the >> result reveal anything about the key or the painttext? > > It better not. That would be a break of amazing simplicity that transcends broken. The question is much more subtle than that, getting deep into how to define a the security of a cipher. Consider a very simplified and limited, but standard, way you'd want to state a security result: A Turing machine with an oracle for computing the encryption of any input with any key, when given as input the cyphertext and allowed to run for time T polynomial in the size of the key, has no more than an probability P less than (something depending on the key size) of guessing any given bit of the plaintext. (OK, I fudged on how you want to state the probability - writing this stuff in English rather than mathematical symbols rapidly becomes unworkable.) The fundamental piece of that statement is in "given as input..." part: If the input contains the key itself, then obviously the machine has no problem at all producing the plaintext! Similarly, of course, if the input contains the plaintext, the machine has an even easier time of it. You can, and people long ago did, strengthen the requirements. They allow for probabilistic machines as an obvious first step. Beyond that, you want semantic security: Not only shouldn't the attacking machine be unable to get an advantage on any particular bit of plaintext; it shouldn't be able to get an advantage on, say, the XOR of the first two bits. Ultimately, you want so say that given any boolean function F, the machine's a postiori probability of guessing F(cleartext) should be identical (within some bounds) to its a priori probability of guessing F(cleartext). Since it's hard to get a handle on the prior probability, another way to say pretty much the same thing is that the probability of a correct guess for F(cleartext) is the same whether the machine is given the ciphertext, or a random sequence of bits. If you push this a bit further, you get definitions related to indistinguishability: The machine is simply expected to say "the input is the result of apply ing the cipher to some plaintext" or "the input is random"; it shouldn't even be able to get an advantage on *that* simple question. This sounds like a very strong security property (and it is) - but it says *nothing at all* about the OP's question! It can't, because the machine *can't compute the XOR of the plaintext and the ciphertext*. If we *give* it that information ... we've just given it the plaintext! I can't, in fact, think of any way to model the OP's question. The closest I can come is: If E(K,P) defines a strong cipher (with respect to any of the variety of definitions out there), does E'(K,P) = E(K,P) XOR P *also* define a strong cipher? One would think the answer is yes, just on general principles: To someone who doesn't know K and P, E(K,P) is "indistinguishable from random noise", so E'(K,P) should be the same. And yet there remains the problem that it's not a value that can be computed without knowing P, so it doesn't fit into the usual definitional/proof frameworks. Can anyone point to a proof? The reason I'm not willing to write this off as "obvious" is an actual failure in a very different circumstance. There was work done at DEC SRC many years ago on a system that used a fingerprint function to uniquely identify modules. The fingerprints were long enough to avoid the birthday paradox, and were computed based on the result of a long series of coin tosses whose results were baked into the code. There was a proof that the fingerprint "looked random". And yet, fairly soon after the system went into production, collisions started to appear. They were eventually tracked down to a "merge fingerprints" operation, which took the fingerprints of two modules and produces a fingerprint of the pair by some simple technique like concatenating the inputs and fingerprinting that. Unfortunately, that operation *violated the assumptions of the theorem*. The theorem said that the outputs of the fingerprint operation would look random *if chosen "without knowledge" of the coi n tosses*. But the inputs were outputs of the same algorithm, hence "had knowledge" of the coin tosses. (And ... I just found the reference to this. See ftp://ftp.dec.com/pub/dec/SRC/research-reports/SRC-113.pdf, documentation of the Fingerprint interface, page 42.) -- Jerry _______________________________________________ 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] Random number generation influenced, HW RNG
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from "James A. Donald" <jamesd(a)echeque.com> ----- Date: Sun, 08 Sep 2013 08:34:53 +1000 From: "James A. Donald" <jamesd(a)echeque.com> To: cryptography(a)randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: jamesd(a)echeque.com On 2013-09-08 3:48 AM, David Johnston wrote: > Claiming the NSA colluded with intel to backdoor RdRand is also to > accuse me personally of having colluded with the NSA in producing a > subverted design. I did not. Well, since you personally did this, would you care to explain the very strange design decision to whiten the numbers on chip, and not provide direct access to the raw unwhitened output. A decision that even assuming the utmost virtue on the part of the designers, leaves open the possibility of malfunctions going undetected. That is a question a great many people have asked, and we have not received any answers. Access to the raw output would have made it possible to determine that the random numbers were in fact generated by the physical process described, since it is hard and would cost a lot of silicon to simulate the various subtle offwhite characteristics of a well described actual physical process. _______________________________________________ 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 08 Sep '13

08 Sep '13

----- Forwarded message from Gregory Perry <Gregory.Perry(a)govirtual.tv> ----- Date: Sat, 7 Sep 2013 21:14:47 +0000 From: Gregory Perry <Gregory.Perry(a)govirtual.tv> To: Phillip Hallam-Baker <hallam(a)gmail.com> Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com>, ianG <iang(a)iang.org> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote: Good theory only the CA industry tried very hard to deploy and was prevented from doing so because Randy Bush abused his position as DNSEXT chair to prevent modification of the spec to meet the deployment requirements in .com. DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF followed the clear consensus of the DNSEXT working group and approved the OPT-IN proposal. The code was written and ready to deploy. I told the IESG and the IAB that the VeriSign position was no bluff and that if OPT-IN did not get approved there would be no deployment in .com. A business is not going to spend $100million on deployment of a feature that has no proven market demand when the same job can be done for $5 million with only minor changes. And this is exactly why there is no real security on the Internet. Because the IETF and standards committees and working groups are all in reality political fiefdoms and technological monopolies aimed at lining the pockets of a select few companies deemed "worthy" of authenticating user documentation for purposes of establishing online credibility. There is no reason for any of this, and I would once again cite to Bitcoin as an example of how an entire secure online currency standard can be created and maintained in a decentralized fashion without the need for complex hierarchies of quasi-political commercial interests. Encrypting SMTP is trivial, it's all about the standard to make it happen. Encrypting IPv6 was initially a mandatory part of the spec, but then it somehow became discretionary. The nuts and bolts of strong crypto have been around for decades, but the IETF and related standards "powers to be" are more interested in creating a global police state than guaranteeing some semblance of confidential and privacy for Internet users. _______________________________________________ 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] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Phillip Hallam-Baker <hallam(a)gmail.com> ----- Date: Sat, 7 Sep 2013 16:20:18 -0400 From: Phillip Hallam-Baker <hallam(a)gmail.com> To: Gregory Perry <Gregory.Perry(a)govirtual.tv> Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com>, ianG <iang(a)iang.org> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" On Sat, Sep 7, 2013 at 3:13 PM, Gregory Perry <Gregory.Perry(a)govirtual.tv>wrote: > >If so, then the domain owner can deliver a public key with authenticity > >using the DNS. This strikes a deathblow to the CA industry. This > >threat is enough for CAs to spend a significant amount of money slowing > >down its development [0]. > > > >How much more obvious does it get [1] ? > > The PKI industry has been a sham since day one, and several root certs > have been compromised by the proverbial "bad guys" over the years (for > example, the "Flame" malware incident used to sign emergency Windows > Update packages which mysteriously only affected users in Iran and the > Middle East, or the Diginotar debacle, or the Tunisian "Ammar" MITM > attacks etc). This of course is assuming that the FBI doesn't already > have access to all of the root CAs so that on domestic soil they can > sign updates and perform silent MITM interception of SSL and > IPSEC-encrypted traffic using transparent inline layer-2 bridging > devices that are at every major Internet peering point and interconnect, > because that would be crazy talk. > Before you make silly accusations go read the VeriSign Certificate Practices Statement and then work out how many people it takes to gain access to one of the roots. The Key Ceremonies are all videotaped from start to finish and the auditors have reviewed at least some of the ceremonies. So while it is not beyond the realms of possibility that such a large number of people were suborned, I think it drastically unlikely. Add to which Jim Bizdos is not exactly known for being well disposed to the NSA or key escrow. Hacking CAs is a poor approach because it is a very visible attack. Certificate Transparency is merely automating and generalizing controls that already exist. But we can certainly add them to S/MIME, why not. -- Website: http://hallambaker.com/ _______________________________________________ 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] Random number generation influenced, HW RNG
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Thor Lancelot Simon <tls(a)panix.com> ----- Date: Sat, 7 Sep 2013 15:36:33 -0400 From: Thor Lancelot Simon <tls(a)panix.com> To: Eugen Leitl <eugen(a)leitl.org> Cc: cryptography(a)randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mutt/1.5.20 (2009-06-14) On Sat, Sep 07, 2013 at 09:05:33PM +0200, Eugen Leitl wrote: > > This pretty much rules out CPU-integral RNGs. It has to be > a third-party add-on (USB or PCIe), and it has to be open hardware. I think you take this more than a little too far. I see CPU-integral RNGs as very valuable source to be mixed with other sources in a software pool of entropy. Why should we reject them, unless we think the mixing functions themselves are useless? The lesson here seems to me to be that we should be far more assiduous in seeking out additional sources of entropy and in always ensuring software RNGs mix input from multiple such sources into all output. We should abandon sacred cows like the notion of information-theoretic randomness (that we don't actually know how to measure, but in pursuit of which we hamstring our software RNGs by arranging that they refuse to produce any output unless, by some questionable criterion, there is enough of it) and pursue engineering goals we can actually achieve, like mixing enough other-source input, of whatever quality, with the output of fast generators we can no longer trust that the adversary must actually attack the mixing function, rather than iteratively guessing the few state bits he does not already know. Secondarily -- and sadly! -- we must now be very suspicious of devices that integrate random number generation and encryption. Can we even trust raw hardware RNG output for the generation of IVs? I would argue not, because the same device's AES engine could be leaking key bits into our explicit IVs, etc, and we couldn't ever know. Devices that offload packet processing in its entirety (SSL accellerators, IPsec accellerators, etc.) have even more opportunity to do this sort of thing. Hardware crypto offload may still be very useful -- random number generation perhaps in particular -- but we will have to apply it with extreme care, and with a deliberate eye towards eliminating covert channels put in place by people at least as smart as we are, and with far more time and experience thinking about the problem from the offensive point of view. Finally, we have to accept that the game might just be over, period. So you use a pure software RNG, mixing in RdRand output or not as you may prefer. How hard do you think it is to identify the datastructures used by that RNG if you can execute code on a coprocessor with access to host RAM? Almost every modern server has such a coprocessor built in (its management processor) and you won't find the source code to its firmware floating around. Intel even puts this functionality directly on its CPUs (Intel AMT). Rather than beating up on the guy who put a lovely RNG instruction into every processor we're likely to use any time soon, it seems to me we ought to be beating up on ourselves for ignoring far simpler and more obvious risks like this one for well over a decade. Seriously, show of hands, who here has ever really put his or her foot down and insisted that a product they were purchasing _omit_ such functionality? Not chosen not to pay for it, refused to buy server X or mainboard Y simply on the basis that management processor functionality was onboard? Now, compare to the number of people complaining about backdoored RNGs here and elsewhere on the Internet. Go figure. To me the interesting question, but one to which I don't expect to ever know the answer, is whether the adversary -- having, we can assume, identified high value devices to systematically compromise, and lower value devices to defer for later or simply ignore entirely -- went at those devices sniper-style, or shotgun-style. Were a few key opportunities for tampering identified, and one or two attempted against each targeted device? Or were a wide variety of avenues explored, and every single one that seemed relevant attempted everywhere, or at least against certain particularly high value devices? If we knew that, in a way we might know, when we did finally see concrete evidence of a particular kind of tampering, how long to keep looking for more. But we aren't going to know that, no matter how much we might want to. Attacks on crypto hardware, attacks on management processors, attacks on supervisory or trusted execution modes seldom exercised in normal system operation, attacks on flash modules holding boot code, so that under the right circumstances they replace page P with evil page P', attacks on elements of IC vendors' standard cell libraries (DMA engines would seem promising); assume the adversaries are smart, and good at their jobs, and the sky would seem to be the limit. The sky will fall, of course, when various nation-states' agencies really start digging for the holes punched in all of our security by the agencies of others (not my own observation, I should note). Too much of this stuff will become all-too-common knowledge. It's going to be quite a ride. But I see no reason to beat up on hardware random number generators *in particular*. They are, at least, tools we may still be able to figure out how to use in a safe way. Thor ----- 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] 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