Some AMD CPU's RDRAND might not return random data after a suspend/resume

Re:Some AMD CPU's RDRAND might not return random data after ... by colmmacc on Tuesday May 07, 2019 @05:00PM (#19853400)

128-bits of random data is sufficient to securely generate a stream of 100s of terabytes of random data. It's not /that/ hard to find 128-bits of true entropy, even during boot phase. Here's one example:

    1. Seed with any fixed hardware IDs

    2. Mix-in the wall clock time

    3. Spin up a kernel thread and flip a bit on/off in a tight loop. Interrupt it every 100 nanoseconds and take the value of the bit at that time. Do this 256 times. Mix that in too.

    4. Mix-in 256-bits from RDRAND 

    5. Mix-in timings from other interrupts as and when they happen. 
 
    6. Repeat steps 4. and 5. ad infinitum.

By step 4 we have taken 26 microseconds and we have the kind of entropy I would be comfortable generating an RSA private key with.

Note that step 3 is effectively a measure of how precise the system clock and CPU are. Attacks have been demonstrated against step 3, but they require co-resident processes and don't apply during the boot-phase, if you've got a dedicated core at least. In theory if system clocks and CPU got super precise it could become too deterministic, but the point is the likelihood of /both/ that happening /and/ RDRAND being broken.

[ Parent | on HN ]

Re:Some AMD CPU's RDRAND might not return random data after ... by Havoc on Tuesday May 07, 2019 @08:26PM (#19854757)

>By step 4 we have taken 26 microseconds and we have the kind of entropy I would be comfortable generating an RSA private key with.

And yet Truecrypt made me wiggle the mouse around for like 30 seconds?

[ Parent | on HN ]

Re:Some AMD CPU's RDRAND might not return random data after ... by ris on Tuesday May 07, 2019 @05:48PM (#19853759)

> 128-bits of random data is sufficient to securely generate a stream of 100s of terabytes of random data.

What you are describing is /dev/urandom. Your argument is basically "urandom is good enough for anybody". If you want to use that, use it.

[ Parent | on HN ]

Re:Some AMD CPU's RDRAND might not return random data after ... by Dylan16807 on Tuesday May 07, 2019 @06:27PM (#19854019)

/dev/urandom is not always sufficiently seeded.

/dev/random makes sure that it's seeded, then pretends it can run out somehow.

getrandom() with default settings is the right behavior almost always, and it took ages to get implemented.

[ Parent | on HN ]