-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardening PRNG #19
Comments
What's the difference between using 32 bytes of random data (thus seeding it from the OS's PRNG) and your proposed method? The only difference I can see is removal of the seed-through-file feature, and the bare minimum guarantee (time, PID, and hw counter which you didn't mention). |
Sorry for my lack of detail as I'm not a cryptographer, but from what I've read, you should never use the time, PID or a hw counter to seed PRNG. The systems PRNG system is able to take in more random sources such as Ethernet interrupt timing and keyboard / mouse input. This isn't very good on embedded hardware, but its better than using the time and/or pid. |
From the OpenSSL documentation:
So basically, there is no point in seeding with /dev/urandom, OpenSSL already uses that device to ensure that the randomness source is properly seeded. |
Is there any reason we should be using RRAND_add() with PID and time data then? I'm not aware of any modern systems without /dev/urandom. My point is tgl has a function tgl_prng_seed that calls RAND_add with data from PID, time and /dev/random. Almost all systems with a /dev/random will have a /dev/urandom. |
Windows, but OpenSSL handles that case too ;)
I guess that those are still fine for additional strengthening, since add_random only adds to the entropy and doesn't "replace" the old random values. Even when they can be guessed it won't do any harm. If we propose any change, we should just remove the pointless calls to /dev/random and /dev/urandom. |
Nearly. There is one extremely important detail, as in "this-is-the-thing-that-might-break-your-neck": You should never use only the time, PID or a hw counter to seed a PRNG. Since we use "secure" sources (explicit entropy from For completeness, let's analyze each part:
The only thing I would modify is the reading of So if you really want to change anything from here, you'd have to convince @vysheng to fully trust the crypto library; both OpenSSL and gcrypt! Only then we can talk about completely removing |
The biggest irony is that the string apparently is discarded adter copying it. So nobody cares about it anyway. Fixes vysheng#19
I noticed that
tgl_prng_seed
is adding Time, PID and 32bytes of random data. It would be best to seed all of the PRNG from random bytes (from each operating systems PRNG system) instead. We could then remove the 2 unused arguments since they are defines to "password" files (currently set to NULL through defines).If there are no objections, I can work on a patch in my own tree and submit a pull request once it is complete.
The text was updated successfully, but these errors were encountered: