4 ms·

Well, you do need to seed /dev/urandom with sufficient entropy. Hardware random number generators work here. After it's seeded, my only concern would be backtra

Well, you do need to seed /dev/urandom with sufficient entropy. Hardware random number generators work here. After it's seeded, my only concern would be backtracking resistence, but haveged(8) works well here.

FiloSottile 10y ago
Yes, but no. The kernel and the OS will take care of seeding for you, and haveged can't create out of thin air any unpredictable events that are somehow invisible to the kernel. Anyway, Linux urandom is backtracking safe as long as SHA-1 preimage security holds.
- atoponce 10y ago
  Well, not all Linux hardware provides sufficient entropy on first boot, such as solid-state embedded hardware or virtual machines. The CSPRNG will happily provide random bits regardless of initial seeding or not. Flip a coin 512 times, record the results, and "echo tththhhhthh... > /dev/random". Most people don't want to do this, so hardware RNGs simplify this. If only the Linux kernel used as entropy everything that was available to it. That's the pitch of haveged(8) I think. There are significantly more timing events the kernel could use for input entropy that it's not. It would be great to see these timing events land in random.c, but they're not there. Lastly, slightly off-topic, but the Linux CSPRNG is poorly designed. In reality, while preimage SHA-1 might still have a sufficient security margin, it suffers from poor performance due to ad-hoc design. Instead, using AES-128 CTR_DRBG with AES-NI would give the kernel CSPRNG a much needed performance boost, provide backtracking resistence, and remain secure. Current testing shows it could improve from 20 MiBps to 2 GiBps.
  - ryuuchin 10y ago
    > Instead, using AES-128 CTR_DRBG Just for comparison this is what Windows does[1] for it's PRNG stuff (in Vista SP1 and newer at least). It uses AES256 in CTR mode as a DRNG[2]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] NIST 800-90

FiloSottile 10y ago

Yes, but no. The kernel and the OS will take care of seeding for you, and haveged can't create out of thin air any unpredictable events that are somehow invisible to the kernel. Anyway, Linux urandom is backtracking safe as long as SHA-1 preimage security holds.

atoponce 10y ago
Well, not all Linux hardware provides sufficient entropy on first boot, such as solid-state embedded hardware or virtual machines. The CSPRNG will happily provide random bits regardless of initial seeding or not. Flip a coin 512 times, record the results, and "echo tththhhhthh... > /dev/random". Most people don't want to do this, so hardware RNGs simplify this. If only the Linux kernel used as entropy everything that was available to it. That's the pitch of haveged(8) I think. There are significantly more timing events the kernel could use for input entropy that it's not. It would be great to see these timing events land in random.c, but they're not there. Lastly, slightly off-topic, but the Linux CSPRNG is poorly designed. In reality, while preimage SHA-1 might still have a sufficient security margin, it suffers from poor performance due to ad-hoc design. Instead, using AES-128 CTR_DRBG with AES-NI would give the kernel CSPRNG a much needed performance boost, provide backtracking resistence, and remain secure. Current testing shows it could improve from 20 MiBps to 2 GiBps.
- ryuuchin 10y ago
  > Instead, using AES-128 CTR_DRBG Just for comparison this is what Windows does[1] for it's PRNG stuff (in Vista SP1 and newer at least). It uses AES256 in CTR mode as a DRNG[2]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] NIST 800-90