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

Minerva: Practically exploitable side-channel leakage in ECDSA implementations

minerva.crocs.fi.muni.cz

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#41

Post by loeg »

regecks wrote: post #40
loeg wrote: post #24

Earlier quoted context omitted.

In new designs or like, SSH keys? For new designs: basically just use libsodium. For SSH: Ed25519 or 2048 bit RSA. We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in de…

>For new designs: basically just use libsodium. Check out libhydrogen from the same author. The API contains less footguns (like nonces).

The appeal of libsodium is that it is (or was) mostly an easy to consume NaCl. Correct me if I'm wrong, but I don't think libhydrogen is related to NaCl or the NaCl authors.

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#42

Post by andyv »

nullc wrote: post #30
wolf550e wrote: post #10

Earlier quoted context omitted.

'tptacek would write that no reputable cryptographer believes the NIST curves themselves are backdoored.

Based on his comments on all matters related to state surveillance and, in particular, on dualec drbg I would take a comment like that from him to be weak evidence that they were backdoored. :) He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist. He clearly has a huge blindspot related to the potential for unlawful and unethical conduct by the US governm…

I already feel stupid about using P-256 a few years ago!

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#43

Post by ohazi »

tialaramex wrote: post #32
1000units wrote: post #18

Earlier quoted context omitted.

Oh, just that once.

We don't actually know for sure that Dual EC is backdoored, we have unexplained constants plus subsequently a way to pick constants that backdoor the algorithm have been discovered. The constants could have been chosen randomly or based on something that would be embarrassing to reveal, e.g. the project leader picked their children's birthdays. Since this algorithm is worse in other ways there is no reason to use it…

We also know that the NSA secretly paid RSA-the-company $10 million to use dual ec as the default.

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#44

Post by mehrdadn »

nullc wrote: post #30
wolf550e wrote: post #10

Earlier quoted context omitted.

'tptacek would write that no reputable cryptographer believes the NIST curves themselves are backdoored.

Based on his comments on all matters related to state surveillance and, in particular, on dualec drbg I would take a comment like that from him to be weak evidence that they were backdoored. :) He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist. He clearly has a huge blindspot related to the potential for unlawful and unethical conduct by the US governm…

> He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist.

Any chance you could list an example or two?

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#45

Post by [deleted] »

bob1029 wrote: post #35
exabrial wrote: post #23

Earlier quoted context omitted.

Finally, read this: "If You’re Typing the Letters A-E-S Into Your Code You’re Doing It Wrong" https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

What's wrong with using AES in CBC mode?

[deleted]

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#46

Post by exabrial »

bob1029 wrote: post #35
exabrial wrote: post #23

Earlier quoted context omitted.

Finally, read this: "If You’re Typing the Letters A-E-S Into Your Code You’re Doing It Wrong" https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

What's wrong with using AES in CBC mode?

See my original comment about attack surface. Given the correct set of circumstances, transmitting the IV in the clear with CBC could possibly open you up to chosen ciphertext/plaintext attacks. And you better be doing encrypt-then-prepend-IV-then-MAC with CBC. Just a lot of gotchas that may or may not be relevant, depending on your environment.

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#47

Post by exabrial »

regecks wrote: post #39
exabrial wrote: post #21

Earlier quoted context omitted.

At minimum, for asymmetric, at the time of the writing: * ECDSA with secp-256 or ed25519 curves * RSA >= 2048 bits. Performance takes a steep dive at 4096bits unfortunately What people don't understand is that your implementation needs to be selected against your attack surface. If your attack surface includes hardening against side channels, your implementation selection needs to take that into account.

I don't think curve25519 is used in any ECDSA implementations. ed25519 is part of EdDSA.

You're correct. ed25519 is a separate scheme.

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#48

Post by wolf550e »

wolf550e wrote: post #8
tptacek wrote: post #6

Earlier quoted context omitted.

But, if you fear and loathe ECDSA (and I do as well), it's probably a good idea to get in early against protocols that seek to deploy more of it. For instance, DNSSEC, which is barely deployed anywhere on the Internet, is just now (as in, resolvers couldn't reliably verify ECC records until recently) introducing ECC support --- with ECDSA.

I think EdDSA desperately needs to be allowed in FIPS certified hardware, so that secure hardware will have support for EdDSA so that people who have to store keys in secure hardware will be able to use it. I mean HSMs, smart cards, secure enclaves, TPMs, things with a ATECC508A, etc.

Can downvoters explain why I'm wrong?

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#49

Post by 1000units »

wolf550e wrote: post #34
tialaramex wrote: post #32

Earlier quoted context omitted.

We don't actually know for sure that Dual EC is backdoored, we have unexplained constants plus subsequently a way to pick constants that backdoor the algorithm have been discovered. The constants could have been chosen randomly or based on something that would be embarrassing to reveal, e.g. the project leader picked their children's birthdays. Since this algorithm is worse in other ways there is no reason to use it…

Reading this [1] and then saying that maybe it's not a backdoor, maybe it's the NSA cryptographer's kids' birthdays is completely nuts. 1 - https://eprint.iacr.org/2016/376.pdf

Some people put their faith in the strangest places.

Re: Minerva: Practically exploitable side-channel leakage in ECDSA implementations

#50

Post by nickpsecurity »

nullc wrote: post #30
wolf550e wrote: post #10

Earlier quoted context omitted.

'tptacek would write that no reputable cryptographer believes the NIST curves themselves are backdoored.

Based on his comments on all matters related to state surveillance and, in particular, on dualec drbg I would take a comment like that from him to be weak evidence that they were backdoored. :) He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist. He clearly has a huge blindspot related to the potential for unlawful and unethical conduct by the US governm…

I'll also add that BULLRUN clearly stated they were backdooring cryptographic standards. At that point, any NSA connection is suspect. Personally, I thought it was brilliant attempt at a NOBUS attack. NOBUS is rarely achievable in practice while simultaneously being deniable.
Post reply on HN