Live data from Hacker News

Minerva: Practically exploitable side-channel leakage in ECDSA implementations

minerva.crocs.fi.muni.cz

31–40 of 55 posts

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

#31

What is the latest "most secure" crypto I should be using?

Start from cryptographic right answers:

https://latacora.singles/2018/04/03/cryptographic-right-answ...

On a glance none of those recommendations have become invalid in the passing 18 months or so.

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

#32
post #13

Earlier quoted context omitted.

There's two stories that often get mixed together. One is an elliptic curve based random number generator (Dual EC DRBG), and yes, everyone who knows the facts believes it's backdoored. Then there's some much more general concerns about the NIST curves themselve. These concerns come down to that a) we don't really know how they were generated (there are some numbers in the paper that just "appear out of nowhere") and…

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 and it's reasonable to treat things that pick Dual EC as problematic because they had no good reason to do that once it became controversial. But we shouldn't forget that it's not actually proven to be backdoored, we have only reasonable suspicions.

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

#33

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 have a lot of competent people at the NSA.

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

#34

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…

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

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

#35

What is the latest "most secure" crypto I should be using?

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?

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

#36

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 do know a lot more than that now. It was in the Snowden leaks.

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

#37

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...

Now that's a deep cut even for a Dan Harmon fan.

For anyone else wondering what the Dan Harmon reference was:

https://en.wikipedia.org/wiki/Heat_Vision_and_Jack

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

#39

What is the latest "most secure" crypto I should be using?

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.

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

#40
post #24

What is the latest "most secure" crypto I should be using?

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).

Post reply on HN