3 ms·

Sigh. This is incorrect. Pi does not give the "nothing up my sleveve" property, because if I have a desired bit sequence in mind, I can find it in Pi, then retr

by kevhito 11y ago

Sigh. This is incorrect. Pi does not give the "nothing up my sleveve" property, because if I have a desired bit sequence in mind, I can find it in Pi, then retroactively claim that because it comes from Pi it wasn't "up my sleeve". Specifically, the methodology of transforming the its of Pi into the desired key was "up my sleeve". What the authors propose here is much better. The methodology and protocol for transforming the seed digits is agreed to ("committed") ahead of time, before the digits are known, and only later are the numbers generated.

tptacek 11y ago
Isn't this circular reasoning? If you do that, you have another constant to justify: the offset into pi you used. Go find BADA55 in Pi, and relay back to us what the offset is.† You don't need lotteries to break this logjam. You just demand the minimal parameters that satisfy the security a/o performance considerations for your problem. LaMacchia and Costello did this for NUMS without even needing recourse to constants: they just start with the target security level, find the minimal prime for that security level, and then the minimal suitable (given, for instance, SafeCurves) d for an Edwards curve. † My friend Peter found it: http://pi.nersc.gov/cgi-bin/pi.cgi?word=BADA55&format=hex http://pi.nersc.gov/cgi-bin/pi.cgi?word=BADA55&format=hex --- so: justify the binary offset "2733181964". :)
bradleyjg 11y ago
The IETF (or whomever) could pre-specify a nothing up my sleeve number algorithm. For example they could choose Pi and say that the following are the official NUMSN for each order of magnitude: 1, 41, 592, 6535, 89793, 238462, 6433832, ... and if a number is needed with a specific property (e.g. 40 digits and prime) than the nearest number to a NUMSN is the official NUMSN for that purpose. Then any future standard that used a constant they claimed was a NUMSN but wasn't complaint with RFC 31415: Procedures of Generating Constants would be suspicious.
cyphar 11y ago
> Sigh. This is incorrect. Pi does not give the "nothing up my sleeve" property, because if I have a desired bit sequence in mind, I can find it in Pi, then retroactively claim that because it comes from Pi it wasn't "up my sleeve". Specifically, the methodology of transforming the its of Pi into the desired key was "up my sleeve". Pi has not been proven to be normal, so you can't be completely sure that you could always find any particularly long (backdoored) sequence.
- Houshalter 11y ago
  No naturally occurring constant has ever been proven to be normal. It's a really hard property to prove. However It's been calculated to billions of digits and it certainly seems to be. It even passes random number tests perfectly.

by kevhito 11y ago

tptacek 11y ago

Isn't this circular reasoning? If you do that, you have another constant to justify: the offset into pi you used. Go find BADA55 in Pi, and relay back to us what the offset is.† You don't need lotteries to break this logjam. You just demand the minimal parameters that satisfy the security a/o performance considerations for your problem. LaMacchia and Costello did this for NUMS without even needing recourse to constants: they just start with the target security level, find the minimal prime for that security level, and then the minimal suitable (given, for instance, SafeCurves) d for an Edwards curve. † My friend Peter found it: http://pi.nersc.gov/cgi-bin/pi.cgi?word=BADA55&format=hex http://pi.nersc.gov/cgi-bin/pi.cgi?word=BADA55&format=hex --- so: justify the binary offset "2733181964". :)

bradleyjg 11y ago

The IETF (or whomever) could pre-specify a nothing up my sleeve number algorithm. For example they could choose Pi and say that the following are the official NUMSN for each order of magnitude: 1, 41, 592, 6535, 89793, 238462, 6433832, ... and if a number is needed with a specific property (e.g. 40 digits and prime) than the nearest number to a NUMSN is the official NUMSN for that purpose. Then any future standard that used a constant they claimed was a NUMSN but wasn't complaint with RFC 31415: Procedures of Generating Constants would be suspicious.

cyphar 11y ago

> Sigh. This is incorrect. Pi does not give the "nothing up my sleeve" property, because if I have a desired bit sequence in mind, I can find it in Pi, then retroactively claim that because it comes from Pi it wasn't "up my sleeve". Specifically, the methodology of transforming the its of Pi into the desired key was "up my sleeve". Pi has not been proven to be normal, so you can't be completely sure that you could always find any particularly long (backdoored) sequence.

Houshalter 11y ago
No naturally occurring constant has ever been proven to be normal. It's a really hard property to prove. However It's been calculated to billions of digits and it certainly seems to be. It even passes random number tests perfectly.