4 ms·

Thanks for the explanation! I was reading the paper but not being an expert I could hardly pass beyond the abstract. So if I understand correctly, the idea wou

by saganus 11y ago

Thanks for the explanation! I was reading the paper but not being an expert I could hardly pass beyond the abstract. So if I understand correctly, the idea would be to have only one curve that has been thoroughly examined for weaknesses and then use that curve and only that curve (ideally) in encryption applications, for example for future versions of TLS or whatever other encryption scheme supports elliptic curves. That would avoid introducing potentially exploitable curves to consumer applications, and maybe even make the NSA's work harder, right? Now my other question is, I'm guessing there's no easy way to determine the rigidity of a curve without the proper knowledge and tools, but if there was a way (let's say some smart guy managed to make an algorithm to determine the curve's weakness) the interested parties could determine the other party's curve weakness and negotiate a minimum level? So if you are using a very nonrigid curve then the other party could say "hey, I won't send encrypted messages to you unless you use a curve's rigidity index > X". Does this make sense? is this were future consumer encryption is/should be moving? EDIT: I'm assuming a nonrigid curve can be considered "weak" by your explanation. A rigid one would be much stronger since it would leave less space for exploitable curves, right?

tptacek 11y ago
It's OK for there to be multiple curve standards. Most curve-enabled applications work with only a few curve standards; in fact, most curve-enabled apps work only with the NIST curves. Everyone implementing a protocol has to agree on which curve they're going to use. There are crazy oddball protocols that attempt to let participants select arbitrary curves, but mainstream applications don't do that. The issue is that you want the standard to be transparent; you want to believe that there's a reason for every parameter in the standard, and that the reason isn't "because this curve is broken". The NIST standards have a bunch of relatively sensible rules for generating the curve parameters they come up with. But they're not rigid, because the first rule, off which every other rule is based, is "start with a random number; here's the random number we came up with, so let's just use that one". The Brainpool standards have relatively sensible rules too. But to keep the process transparent, they start with a mathematical constant, in a sort of "who could argue with pi" argument. Bernstein's point is that the space of all permutations of a pretty small set of mathematical constants gives you a lot of room to find a weak curve. Maybe it's sqrt(2)+sin(2)+e/pi. Well, then you, the bad guy, just write a standards doc that says "the square root of 2, sin(2), e, and pi are fundamental mathematical constants that we chose so nobody has to worry we made up numbers to find a weak curve". I'm simplifying, but just a little.

by saganus 11y ago

tptacek 11y ago

It's OK for there to be multiple curve standards. Most curve-enabled applications work with only a few curve standards; in fact, most curve-enabled apps work only with the NIST curves. Everyone implementing a protocol has to agree on which curve they're going to use. There are crazy oddball protocols that attempt to let participants select arbitrary curves, but mainstream applications don't do that. The issue is that you want the standard to be transparent; you want to believe that there's a reason for every parameter in the standard, and that the reason isn't "because this curve is broken". The NIST standards have a bunch of relatively sensible rules for generating the curve parameters they come up with. But they're not rigid, because the first rule, off which every other rule is based, is "start with a random number; here's the random number we came up with, so let's just use that one". The Brainpool standards have relatively sensible rules too. But to keep the process transparent, they start with a mathematical constant, in a sort of "who could argue with pi" argument. Bernstein's point is that the space of all permutations of a pretty small set of mathematical constants gives you a lot of room to find a weak curve. Maybe it's sqrt(2)+sin(2)+e/pi. Well, then you, the bad guy, just write a standards doc that says "the square root of 2, sin(2), e, and pi are fundamental mathematical constants that we chose so nobody has to worry we made up numbers to find a weak curve". I'm simplifying, but just a little.