4 ms·

Would it be reasonable for the library to almost make a "good attempt at making a nonce, perhaps by using a global counter, date time, uptime and reading /dev/r

Would it be reasonable for the library to almost make a "good attempt at making a nonce, perhaps by using a global counter, date time, uptime and reading /dev/random? Then nonce collision would require a library submitting identical nonces, identical messages, and basically every way of getting a unique number from the OS to all collide.

lvh 9y ago
Sorta: if your CSPRNG is weird/broken then you have way worse problems, so just use your CSPRNG. If your CSPRNG is fine, adding global counters, timestamps, uptime... makes no sense. (Also, you should use /dev/urandom, not /dev/random. Or getentropy/getrandom/CryptGenRandom, depending on your OS.)
- CJefferson 9y ago
  CSPRNG can be badly behaved at startup time on virtual machines, and there have been problems with bad random numbers at start up time. Adding wall clock time to the mix wouldn't hurt.
  - lvh 9y ago
    Which operating system do you run where time isn't already in the CSPRNG pool?
    - CJefferson 9y ago
      I believe Linux only uses physical devices (which are very limited in some VMs), but this might just be folk-legend (I haven't read the source).
      - lvh 9y ago
        No, Linux' random.c has add_device_randomness (sp? it's definitely something_device_randomness), which includes a bunch of machine-specific things to the RNG, including MAC addresses, serial numbers, and, crucially, the RTC.
        CJefferson 9y ago
        I'm obviously misinformed. Thanks for that.
deleted 9y ago
[deleted]
mikedilger 9y ago
This will depend on the length of the nonce (which depends on the algorithm). With shorter nonces (64 bits), it is strongly recommended to use a counter. You can start at zero, or if you prefer, start at a random number or use a LFSR whose cycle is 2^64. That way you know for sure that the first 2^64 nonces are all unique. If random generation was used, you would hit collisions due to the birthday paradox, and by 2^32 nonces the chance of a collision would be about 40% [1]. With long nonces (192 bits), you can use random generation entirely, given that you have a good CSPRNG. With intermediate nonces, it might be reasonable to use a 64-bit counter and either randomize the rest or use clock data (if you have a system with good clocks). This gives a little protection against any sort of nonce-reset bug in your code, while still giving you a full 2^64 nonces before the counter cycles. But this is just my own opinion, and I'm not a professional cryptographer (although I did study under Philip Rogaway). It seems imminently more likely for a counter to get reset by a code bug (e.g. KRACK), then for a largish random number to repeat, so I understand why coders instinctively lead towards random numbers rather than counters. [1] https://eprint.iacr.org/2016/475.pdf https://eprint.iacr.org/2016/475.pdf, see table page 6

lvh 9y ago

Sorta: if your CSPRNG is weird/broken then you have way worse problems, so just use your CSPRNG. If your CSPRNG is fine, adding global counters, timestamps, uptime... makes no sense. (Also, you should use /dev/urandom, not /dev/random. Or getentropy/getrandom/CryptGenRandom, depending on your OS.)

CJefferson 9y ago
CSPRNG can be badly behaved at startup time on virtual machines, and there have been problems with bad random numbers at start up time. Adding wall clock time to the mix wouldn't hurt.
- lvh 9y ago
  Which operating system do you run where time isn't already in the CSPRNG pool?
  - CJefferson 9y ago
    I believe Linux only uses physical devices (which are very limited in some VMs), but this might just be folk-legend (I haven't read the source).
    - lvh 9y ago
      No, Linux' random.c has add_device_randomness (sp? it's definitely something_device_randomness), which includes a bunch of machine-specific things to the RNG, including MAC addresses, serial numbers, and, crucially, the RTC.
      - CJefferson 9y ago
        I'm obviously misinformed. Thanks for that.

deleted 9y ago

[deleted]

mikedilger 9y ago

This will depend on the length of the nonce (which depends on the algorithm). With shorter nonces (64 bits), it is strongly recommended to use a counter. You can start at zero, or if you prefer, start at a random number or use a LFSR whose cycle is 2^64. That way you know for sure that the first 2^64 nonces are all unique. If random generation was used, you would hit collisions due to the birthday paradox, and by 2^32 nonces the chance of a collision would be about 40% [1]. With long nonces (192 bits), you can use random generation entirely, given that you have a good CSPRNG. With intermediate nonces, it might be reasonable to use a 64-bit counter and either randomize the rest or use clock data (if you have a system with good clocks). This gives a little protection against any sort of nonce-reset bug in your code, while still giving you a full 2^64 nonces before the counter cycles. But this is just my own opinion, and I'm not a professional cryptographer (although I did study under Philip Rogaway). It seems imminently more likely for a counter to get reset by a code bug (e.g. KRACK), then for a largish random number to repeat, so I understand why coders instinctively lead towards random numbers rather than counters. [1] https://eprint.iacr.org/2016/475.pdf https://eprint.iacr.org/2016/475.pdf, see table page 6