Live data from Hacker News

Why we don’t generate elliptic curves every day

words.filippo.io

1–10 of 54 posts

Re: Why we don’t generate elliptic curves every day

#2
Curious to hear someone with more expertise than me opine on the validity of brute forcing standardized parameters, which doesn't seem to be discussed in article.

Are standardized elliptical curves still susceptible to being "individually" broken in ECDH in practice? Or are there other subsequent randomized mechanisms to accomplish forward secrecy / per session resistance?

I understand the article's point against diversity, but there seems a gap of the "G20 nation states have orders of magnitude more resources than everyone else" variety. Even if something is ridiculously computationally intensive for everyone, it can be feasible given Manhattan Project level resources, if the payoff is worth it.

Re: Why we don’t generate elliptic curves every day

#3
post #2

Curious to hear someone with more expertise than me opine on the validity of brute forcing standardized parameters, which doesn't seem to be discussed in article. Are standardized elliptical curves still susceptible to being "individually" broken in ECDH in practice? Or are there other subsequent randomized mechanisms to accomplish forward secrecy / per session resistance? I understand the article's point against div…

You could have one side generate new keys for every session. That's how WebPush encryption works, if you're looking for an implementation. Client has a static public key stored on the server, server generates a per message ECDH key and embeds the pub key in the message.

Re: Why we don’t generate elliptic curves every day

#4
TIL that there are known attacks on primality testing routines, where the test will accept as prime a composite number. Vulnerable libraries at the time of the paper (2018) included OpenSSL, GMP, Apple, JSBN, Cryptlib, LibTomMath, LibTomCrypt, WolfSSL, Bouncy Castle and Botan.

Re: Why we don’t generate elliptic curves every day

#6
post #2

Curious to hear someone with more expertise than me opine on the validity of brute forcing standardized parameters, which doesn't seem to be discussed in article. Are standardized elliptical curves still susceptible to being "individually" broken in ECDH in practice? Or are there other subsequent randomized mechanisms to accomplish forward secrecy / per session resistance? I understand the article's point against div…

Every P-256 or X25519 ECDH operation uses a new ephemeral single-use key breaking which is about as hard as brute forcing AES-128. Global bitcoin hash rate is something like 90 bits per year. People think NSA doesn't have more hardware than all the bitcoin miners together. If they can break 128 bit security, they can't break it for every roundtrip in a Signal chat. I don't know what they would even use the capability to do. I don't think they need brute force to forge a Microsoft or Apple signature - easier to steal it. But it would be something high value that would be broadly useful, not a single message.

Re: Why we don’t generate elliptic curves every day

#8
post #7

The author never addresses the issue of trusting standard parameters. I agree with them on the rest, but standard parameters need evidence that they were not specially selected for reasons unknown to everyone else.

Footnote [1] is about different strategies to select trustworthy standard parameters. I believe they are all good enough to make it so that if someone can still "backdoor" the result, they are so far ahead of the outside world that they might as well have broken the whole scheme, without influencing the parameters.

[1] https://words.filippo.io/dispatches/parameters/#fn1

(Yes, I hide too much stuff in the footnotes.)

Re: Why we don’t generate elliptic curves every day

#9
post #6
post #2

Curious to hear someone with more expertise than me opine on the validity of brute forcing standardized parameters, which doesn't seem to be discussed in article. Are standardized elliptical curves still susceptible to being "individually" broken in ECDH in practice? Or are there other subsequent randomized mechanisms to accomplish forward secrecy / per session resistance? I understand the article's point against div…

Every P-256 or X25519 ECDH operation uses a new ephemeral single-use key breaking which is about as hard as brute forcing AES-128. Global bitcoin hash rate is something like 90 bits per year. People think NSA doesn't have more hardware than all the bitcoin miners together. If they can break 128 bit security, they can't break it for every roundtrip in a Signal chat. I don't know what they would even use the capability…

and more importantly, any operation that needs that much compute power can be more efficiently solved by passing around a couple billion dollars of bribes

Re: Why we don’t generate elliptic curves every day

#10
post #7

The author never addresses the issue of trusting standard parameters. I agree with them on the rest, but standard parameters need evidence that they were not specially selected for reasons unknown to everyone else.

Footnote [1] is about different strategies to select trustworthy standard parameters. I believe they are all good enough to make it so that if someone can still "backdoor" the result, they are so far ahead of the outside world that they might as well have broken the whole scheme, without influencing the parameters. [1] https://words.filippo.io/dispatches/parameters/#fn1 (Yes, I hide too much stuff in the footnotes.)

Out of curiosity, have people considered rigidly defining requirements, but rather than picking the simplest/lowest value that satisfies the requirements, instead having a public “parameter choice ceremony” using a multiparty random number generation protocol to pick a random value that satisfies the requirements? That seems like it would make it much harder to manipulate the value by changing the requirements.
Post reply on HN