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

Why we don’t generate elliptic curves every day

words.filippo.io

Post reply on HN
Print view View original

31–40 of 54 posts

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

#31

Post by karelpeeters »

tptacek wrote: post #12
phkahler wrote: 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.

You're never going to get a satisfactory answer. The world's foremost proponent of not trusting standardized parameters wrote and repeatedly submitted a paper demonstrating a model attack that targeted curves built from mathematical constants; when you've "backdoored pi", there's really no place to go from there. That author's subtext, as I understood it, was that curves should be selected by functional optimization;…

Could you share the paper(s) about "backdoors" in physical constants? That doesn't make much sense at first sight.

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

#32

Post by woodruffw »

comex wrote: post #10
FiloSottile wrote: post #8

Earlier quoted context omitted.

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.

This probably leads to regress (why trust the multiparty scheme?), and would only be convincing to a tiny fraction of skeptics (asymptotically, the ones who are least likely to be cranks and therefore the least noisy ones).

Meanwhile, a big part of current cryptographic design is recognizing that many of our current primitives have far larger margins than we really need, and that we can squeeze performance out of our schemes by taking a more evidence-based approach to parameter selection/round counts/etc.[1].

[1]: https://eprint.iacr.org/2019/1492

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

#33

Post by UncleMeat »

karelpeeters wrote: post #31
tptacek wrote: post #12

Earlier quoted context omitted.

You're never going to get a satisfactory answer. The world's foremost proponent of not trusting standardized parameters wrote and repeatedly submitted a paper demonstrating a model attack that targeted curves built from mathematical constants; when you've "backdoored pi", there's really no place to go from there. That author's subtext, as I understood it, was that curves should be selected by functional optimization;…

Could you share the paper(s) about "backdoors" in physical constants? That doesn't make much sense at first sight.

https://bada55.cr.yp.to/bada55-20150927.pdf

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

#34

Post by hyper_reality »

euicnon wrote: post #30

Are there cryptographers with dissenting opinions to this article, or is what the author writes about generally recognised best practice? I ask because I remember an article a while back where this same author had very confidently got some details wrong about CloudFlare and I think the CEO or CTO or someone like that had to step in and correct him.

Are you sure you're thinking of the right author? Filippo used to work at Cloudflare so I can't imagine he got the technical details about it too wrong.

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

#35

Post by bmulcahy »

tptacek wrote: post #12
phkahler wrote: 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.

You're never going to get a satisfactory answer. The world's foremost proponent of not trusting standardized parameters wrote and repeatedly submitted a paper demonstrating a model attack that targeted curves built from mathematical constants; when you've "backdoored pi", there's really no place to go from there. That author's subtext, as I understood it, was that curves should be selected by functional optimization;…

>but because the mechanism by which they were generated would result in whole large classes of broken curves that academic cryptography and mathematics would have caught by now

Might such discoveries by academics be forcibly suppressed by government agencies?

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

#36

Post by quesera »

oh_sigh wrote: post #15
tptacek wrote: post #12

Earlier quoted context omitted.

You're never going to get a satisfactory answer. The world's foremost proponent of not trusting standardized parameters wrote and repeatedly submitted a paper demonstrating a model attack that targeted curves built from mathematical constants; when you've "backdoored pi", there's really no place to go from there. That author's subtext, as I understood it, was that curves should be selected by functional optimization;…

Hell, even picking seeds like "the text of the NYT headline from [future date]", since the FBI or some other shadowy governmental organization could lean on the NYT editor to construct the headline in a manner that is useful to them

Hmm. How about asking all members of the UN to produce 8 "random" bytes. Concatenate in ISO alpha order, hash the result.

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

#37

Post by mattsan »

bmulcahy wrote: post #35
tptacek wrote: post #12

Earlier quoted context omitted.

You're never going to get a satisfactory answer. The world's foremost proponent of not trusting standardized parameters wrote and repeatedly submitted a paper demonstrating a model attack that targeted curves built from mathematical constants; when you've "backdoored pi", there's really no place to go from there. That author's subtext, as I understood it, was that curves should be selected by functional optimization;…

>but because the mechanism by which they were generated would result in whole large classes of broken curves that academic cryptography and mathematics would have caught by now Might such discoveries by academics be forcibly suppressed by government agencies?

I would argue that suppression of public individuals would be much more difficult than say the NSA just scooping up the best mathematicians in that field

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

#38

Post by ZoomerCretin »

PartiallyTyped wrote: post #20
thadt wrote: post #11

Earlier quoted context omitted.

Brute force? I don't think so. Orders of magnitude in brute force are sometimes easier to look at as raw numbers. If we take the sibling comments estimate of the global BitCoin network's total computation of 2^90, multiply it arbitrarily by three orders of magnitude we get: 2^90 = 1237940039285380000000000000 2^90 * 1000 = 1237940039285380000000000000000 2^128 = 340282366920938000000000000000000000000 Even G20 nation…

… or another stuxnet even.

Already exists: https://en.wikipedia.org/wiki/Intel_Management_Engine#Securi...

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

#39

Post by helpfulclippy »

The author proposes a corollary to Kerckhoff's principle:

> A cryptosystem should be secure even if all the parameters, except the key, are shared across every user.

It seems that if the key counts as a parameter, then surely nonces also count, and we certainly do not want nonces to be reused. This may be why this principle is not best practice. I am quite confident that the author is well aware of this, and I agree with the general thrust of what they're saying... Perhaps another way of saying it is that where parameters can be held constant, they should be. Or to quote Daniel J. Bernstein[1] quoting Mark Twain:

> Behold, the fool saith, "Put not all thine eggs in the one basket"—which is but a manner of saying, "Scatter your money and your attention;" but the wise man saith, "Put all your eggs in the one basket and—WATCH THAT BASKET."

[1]: https://blog.cr.yp.to/20140205-entropy.html

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

#40

Post by d-z-m »

helpfulclippy wrote: post #39

The author proposes a corollary to Kerckhoff's principle: > A cryptosystem should be secure even if all the parameters, except the key, are shared across every user. It seems that if the key counts as a parameter, then surely nonces also count, and we certainly do not want nonces to be reused. This may be why this principle is not best practice. I am quite confident that the author is well aware of this, and I agree…

[removed for irrelevance]
Post reply on HN