Re: [cryptography] regarding the NSA crypto breakthrough
On 06/09/13 21:21, Tony Arcieri wrote: There are curves not selected by e.g. NIST with a published rationale for their selection, like Curve25519. Is there any reason why such curves can't be evaluated retroactively? http://cr.yp.to/ecdh/curve25519-20060209.pdf https://twitter.com/hashbreaker/status/375887883900432385 Curve25519 is y^2=x^3+486662x^2+x mod 2^255-19. Nothing random; all details justified in the paper. Vatican hasn't complained about the 666. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Compositing Ciphers?
We have a purely (now mostly) all-symmetric key protocol: Needham-Schroeder -- Kerberos. Guess what: it doesn't scale, not without a strong dose of PK (and other things). Worse, its trusted third parties can do more than MITM/impersonate you like PKI's: they get to see your session keys (unless you add PFS, of course). For PFS you need assymetric crypto. To scale you need asymmetric crypto *and* trusted third parties. To communicate at all you need peers to communicate with, peers who can turn on you, or just plain screw up, or get conned. Square #1, how well we know thee. Symmetric-only crypto isn't the answer, and evidently neither is PK crypto. With or without crypto, our problems are human problems. A combination of PK and symmetric crypto is the best we can do in a classical world, and transitive trust is the only way to scale to billions (or even just a few tens of thousands) of people. All of which means that there will always be some degree of insecurity, as it always was before the modern era, and as it has to be. Because we have free will. I don't know what a post-quantum number factoring world will look like... a bit bleak I guess, at least for a while, but hardly much bleaker than much of the past one hundred years. BTW, if it's the PRISMs that animate you: that is the land of politics; and crypto is not the answer you seek, it's just a tool. A tool that might play a bi[tg] part in debates and their outcomes, but still, just a tool, not a panacea. [In theory Kerberos with hierarchical and web of trust could scale. No one has attempted to scale it past a few .EDUs and a few .MILs,. With PKINIT and PKCROSS -- bridges to PK[I] -- and trust routing it could scale, and it'd then have roughly the properties PKI could have / should have had with OCSP done right (i.e., stapled, and from the get-go). Kerberos still has a long life ahead of it in corporate and university networks, I'm fairly certain of that. But without PK it can't scale to Internet scale. I don't think any other all-symmetric key cryptographic protocols can do better than Needham-Schroeder.] Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Compositing Ciphers?
Jeffrey Walton noloa...@gmail.com wrote:
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 did a paper on that sort of thing a while back:
http://eprint.iacr.org/2008/473
A much improved version is in the works, but not done.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] what has the NSA broken?
On 9/6/2013 6:58 AM, Ralph Holz wrote: Hi, On 09/06/2013 07:12 AM, James A. Donald wrote: Most private keys are issued by, not merely certified by, the CAs. Can you give numerical evidence for this claim? Device certificates (those that go into mass manufactured products) typically have the CA provide both keys and cert. The back and forth of keygen-CSR-Sign-Return per product does not fit in the mindset of a manufacturer. I suspect this is more certs than all the web site certs put together. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On 9/6/2013 2:03 PM, grarpamp wrote: Does anyone put any stock into the rumors floating lately that the government may have influenced Intel and/or AMD into altering However, I claim that the fear is well founded and should be taken into account by all threat models. It interesting to consider the possibilities of corruption and deception that may exist in product design. It's a lot more alarming when it's your own design that is being accused of having been backdoored. 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. A quick googling revealed many such instances of statements to this effect, strewn across the internet, based on inferences from the Snowden leaks and resulting Guardian and NYT articles. I personally know it not to be true and from my perspective, the effort we went to improve computer security by making secure random numbers available and ubiquitous in a low attack-surface model is now being undermined by speculation that would lead people to use less available, less secure RNGs. This I expect would serve the needs of the NSA well. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-talk] NIST approved crypto in Tor?
- Forwarded message from Nick Mathewson ni...@alum.mit.edu - Date: Sat, 7 Sep 2013 13:02:04 -0400 From: Nick Mathewson ni...@alum.mit.edu To: tor-t...@lists.torproject.org tor-t...@lists.torproject.org Subject: Re: [tor-talk] NIST approved crypto in Tor? Reply-To: tor-t...@lists.torproject.org On Sat, Sep 7, 2013 at 5:25 AM, Sebastian G. bastik.tor bastik@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
Re: [cryptography] Random number generation influenced, HW RNG
On Sat, Sep 7, 2013 at 1:48 PM, David Johnston d...@deadhat.com wrote: On 9/6/2013 2:03 PM, grarpamp wrote: ... However, I claim that the fear is well founded and should be taken into account by all threat models. It interesting to consider the possibilities of corruption and deception that may exist in product design. It's a lot more alarming when it's your own design that is being accused of having been backdoored. 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. I don't think it was a personal attack. A quick googling revealed many such instances of statements to this effect, strewn across the internet, based on inferences from the Snowden leaks and resulting Guardian and NYT articles. Its our job to be paranoid. As long as our adversaries enjoy secrecy (and no responsibility or accountability), we have to speculate on capabilities. I personally know it not to be true and from my perspective, the effort we went to improve computer security by making secure random numbers available and ubiquitous in a low attack-surface model is now being undermined by speculation that would lead people to use less available, less secure RNGs. This I expect would serve the needs of the NSA well. Well, because you did not know or participate does not mean it did not occur. In [1], Caspar Bowden, who was the former Chief Privacy Officer at Microsoft, speculated a handful of top Microsoft managers were involved with the backdooring of Microsoft products. Even Bowden was not privileged to the full depth and breadth of corporate cooperation. If you asked David LeBlanc, Michael Howard, and a number of other senior security guys, they likely had no knowledge either. Jeff [1] https://www.youtube.com/watch?v=-Cx_vumGbXM. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
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@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generation being influenced - rumors
On 2013-09-07 9:14 PM, Eugen Leitl wrote: 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. On chip whitening is extremely suspicious behavior. Since the need for random numbers is low bandwidth, on chip whitening is a waste of silicon. Despite repeated requests, the decision to do whitening on chip has never been explained. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote: 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. You know as soon as anyone complained about this, they turned around and provided access to the unwhitened output in the next major version of the same product family, right? A decision that even assuming the utmost virtue on the part of the designers, leaves open the possibility of malfunctions going undetected. And one that echoes what about 50% of the other people who have built hardware random number generators also made. That is a question a great many people have asked, and we have not received any answers. No answers aside from Intel actually providing exactly what you asked for, next chance they got. 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. I am extremely skeptical of this claim. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On 2013-09-08 1:25 PM, Thor Lancelot Simon wrote: On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote: 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. You know as soon as anyone complained about this, they turned around and provided access to the unwhitened output in the next major version of the same product family, right? I am not aware of this. Could you provide further details? And since no one needs high bandwidth true random numbers, why the on chip whitening? Surely there was some internal discussion of this decision? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
