Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What encryption algorithms should we take as compromised?

news.ycombinator.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Ask HN: What encryption algorithms should we take as compromised?

#41

Post by tptacek »

pja wrote: post #35
tptacek wrote: post #28

Earlier quoted context omitted.

The word "may" is doing a lot of work in the sentence "may have been backdoored". What cryptographers are observing about the NIST P- curves is that it isn't impossible for them to have been backdoored; that there is a plausible technique that NSA could have used, given some an advance in ECC cryptanalysis unknown to public science but known to them, that could result in a backdoor. Everything beyond that is the prec…

Your glass appears to be half full, mine half empty :)

No, it's not; the fullness of our glasses is orthogonal to the specific cryptographic issue we're discussing. I would recommend against the NIST P- curves.

One fortunate result of the Snowden disclosures is that for several reasons, some rational and some irrational, the market value of NIST/FIPS certification has plummeted --- it's still an issue if you're selling to the government, but no longer carries security cachet.

As a result, there's minimal upside to adopting cryptographic primitives and constructions simply because they have NIST standards backing them. Which means there's minimal upside to using the NIST curves.

Meanwhile, there are multiple downsides. One of them is the potential for backdoors, but I don't need to reach that issue in my analysis because another is the difficulty of safely implementing curve software with the NIST P-curves.

Re: Ask HN: What encryption algorithms should we take as compromised?

#42

Post by tptacek »

cliveowen wrote: post #4

It's not just about compromised encryption algorithms, it's also about picking the right algorithm for a given purpose. For instance, an hashing algorithm can be used to securely store passwords, and must therefore be slow, or to find duplicate files, a task which greatly benefits from speed. If you use a fast hashing algorithm to "securely" store passwords you might as well use a compromised algorithm since the secu…

You might save yourself trouble by thinking of a "hash algorithm" as an infrequently-used primitive, a password hash (or KDF) as something you'd store a password authenticator with.

Re: Ask HN: What encryption algorithms should we take as compromised?

#43

Post by tptacek »

p4bl0 wrote: post #7
StavrosK wrote: post #6

Earlier quoted context omitted.

Nobody is arguing against that. The OP is asking about compromised algorithms. Sure, non-compromised algorithms can still be used incorrectly and be insecure, but compromised ones won't be secure no matter how they're used. Also, you don't use hashes to store passwords, you use KDFs.

> Also, you don't use hashes to store passwords, you use KDFs. Well, technically a hash can be seen as a particular key derivation function (KDF). Not a proper one for the purpose of storing passwords I agree, but then most KDFs are built using salt + an iteration of hash functions, to my knowledge at least (which I admit is not very deep on the subject).

A hash serves as the PRF in a KDF construction; it's a building block, not a subset.

Re: Ask HN: What encryption algorithms should we take as compromised?

#45

Post by acqq »

elliotz wrote: post #19
acqq wrote: post #8

Earlier quoted context omitted.

> If you use those curves, then you're revealing your secrets to the NSA but not to anyone else. ...until some worker or contractor takes their "secret" values for himself, or sells them, or publishes them on the internet. Producing the public standards with the built-in master keys increases possibility of overnight global breakage.

The public standard shouldn't include the secret values, but rather identify the (verifiable) process for generating the public values, in order to assure people that they were not created from secret values. See: https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number (Or, of course, you could just not publish RNG standards based on public-key crypto ;-)

> The public standard shouldn't include the secret values

It seems there's enough evidence that NSA inserted the secret values in one standard already:

http://en.wikipedia.org/wiki/Dual_EC_DRBG

Re: Ask HN: What encryption algorithms should we take as compromised?

#46

Post by cperciva »

tptacek wrote: post #30
sillysaurus3 wrote: post #10

If you're wondering what isn't compromised, the information here has withstood the test of time and scrutiny from the crypto community: http://www.daemonology.net/blog/2009-06-11-cryptographic-rig... Barring some major advance in breaking crypto (which is entirely possible) it will probably stand for a long time to come.

That is the charitable way to describe Colin's suggestions. Another way to describe them is "well-aged", or "conservative". Here are more modern alternatives to each of Colin's suggestions: * Message encryption: AES-CTR+HMAC -> A fast native stream cipher (Salsa20) + polynomial MAC (Poly1305, VMAC). * Standalone integrity checking: HMAC -> HMAC or SHA3. * Hash: BLAKE2 or SHA3. * Passwords: scrypt or, if not available…

Another way to describe them is "well-aged", or "conservative".

I absolutely agree. I am 100% in favour of being conservative when choosing cryptographic primitives.

All the alternatives you've mentioned have arguments in their favour. But unless you need to have signatures which are 32 bytes instead of 256 bytes, or you need to perform 10,000 private key operations per second instead of 1,000, or you need to build an ASIC which uses a few thousand fewer transistors, my recommendation is to be conservative.

Re: Ask HN: What encryption algorithms should we take as compromised?

#47

Post by vbuterin »

tptacek wrote: post #20
vbuterin wrote: post #18

SHA256, SHA3, AES, ECDSA and ECDH/ECIES are all good, plus one-time pads and Shamir's secret sharing. There's no real need to use anything else.

SHA256 is an instance of SHA2. Presumably you didn't mean that SHA512 was bad, or, better, SHA512/256. ECDSA, ECDH, and ECIES (which we don't see a lot of) all require a curve. Saying "ECDH is good" isn't helpful if you can't safely choose a curve to run them over. ECDSA has another problem: it has a hard randomness requirement. If you repeat the per-message nonce, leak bits of the message nonce, or even fail to fill…

> SHA256 is an instance of SHA2. Presumably you didn't mean that SHA512 was bad, or, better, SHA512/256.

Right. But I don't see a reason why you would ever want either of those when SHA256 works just fine. Maybe because it's a bit more efficient per byte as a PRNG, but there are better specialized tools for that.

> ECDSA has another problem: it has a hard randomness requirement.

Not if you use RFC6979. In the Bitcoin space that's been standard since about three days after the Java.SecureRandom bug. As for curves, secp256k1 and curve25519 seem to be the most popular as far as I can tell.

> One-time pads are awful and should be avoided at all costs. Virtually every computer program developed by generalist programmers that claimed to be a "one-time pad" was instead a crappy stream cipher.

Well, yes, an OTP generated by a PRNG is a stream cipher by definition. You do need true randomness for them to work. I think they're very useful if (1) you're scared that NSA has a constructive proof of P=NP deep inside their lairs, or (2) you want ultimate deniable encryption.

Re: Ask HN: What encryption algorithms should we take as compromised?

#48

Post by tptacek »

cperciva wrote: post #46
tptacek wrote: post #30

Earlier quoted context omitted.

That is the charitable way to describe Colin's suggestions. Another way to describe them is "well-aged", or "conservative". Here are more modern alternatives to each of Colin's suggestions: * Message encryption: AES-CTR+HMAC -> A fast native stream cipher (Salsa20) + polynomial MAC (Poly1305, VMAC). * Standalone integrity checking: HMAC -> HMAC or SHA3. * Hash: BLAKE2 or SHA3. * Passwords: scrypt or, if not available…

Another way to describe them is "well-aged", or "conservative". I absolutely agree. I am 100% in favour of being conservative when choosing cryptographic primitives. All the alternatives you've mentioned have arguments in their favour. But unless you need to have signatures which are 32 bytes instead of 256 bytes, or you need to perform 10,000 private key operations per second instead of 1,000, or you need to build a…

I wonder whether I might not be able to convince you that RSA is less conservative than ECC. Certainly, I haven't once tested a piece of real-world software that got it right. Did you see that just the other day, a team managed to resurrect the PKCS1v15 padding oracle in JSSE? Is RSA plus OAEP really simpler than just using a curve to derive a key to encrypt with?

Re: Ask HN: What encryption algorithms should we take as compromised?

#49

Post by tptacek »

vbuterin wrote: post #47
tptacek wrote: post #20

Earlier quoted context omitted.

SHA256 is an instance of SHA2. Presumably you didn't mean that SHA512 was bad, or, better, SHA512/256. ECDSA, ECDH, and ECIES (which we don't see a lot of) all require a curve. Saying "ECDH is good" isn't helpful if you can't safely choose a curve to run them over. ECDSA has another problem: it has a hard randomness requirement. If you repeat the per-message nonce, leak bits of the message nonce, or even fail to fill…

> SHA256 is an instance of SHA2. Presumably you didn't mean that SHA512 was bad, or, better, SHA512/256. Right. But I don't see a reason why you would ever want either of those when SHA256 works just fine. Maybe because it's a bit more efficient per byte as a PRNG, but there are better specialized tools for that. > ECDSA has another problem: it has a hard randomness requirement. Not if you use RFC6979. In the Bitcoin…

SHA512/256 is safer than SHA256, for more than one reason. secp256k1 is "popular" for cryptocoins.
Post reply on HN