Randomizer: always use CSPRNG from OpenSSL #54
Conversation
|
|
thillux
force-pushed
the
csprng-fixes
branch
from
7a3f2d6 to
33438a8
Compare
|
I was too stupid to get |
thillux
force-pushed
the
csprng-fixes
branch
4 times, most recently
from
e328d0a to
3076429
Compare
|
Thanks for your pull request. We will look into this soon and cooperate with the BSI. The OpenSSL randomizer is always seeded by OpenSSL itself. RAND_seed won't "reset" the entropy. It will add more entropy like RAND_add. |
thillux
force-pushed
the
csprng-fixes
branch
from
d5a9f7c to
3076429
Compare
The Randomizer class provided an insecure mersenne twister PRNG as a convenience method to draw things like PINs and serial numbers from it. I changed this to always use a secure OpenSSL-based CSPRNG. Furthermore, the OpenSSL PRNG was insecurely seeded from the mersenne twister RNG. Fix this, by combining several input sources via a cryptographic hash function and seed OpenSSL from it. The code now tries to read 256 Bit from different sources and combines them, with SHA-512. When OpenSSL aims for 256 Bit security strength, seed it with at least 1.5x this security strength. Please note, that OpenSSL in typical configurations is automatically seeded and the seeding strategy here probably did no harm by accident in the past. Signed-off-by: Markus Theil <[email protected]>
thillux
force-pushed
the
csprng-fixes
branch
from
3076429 to
274ee67
Compare
|
Do you have update(s) on this? |
|
One further question: do you plan to secure the UD <-> Remote-IFD pairing mechanism, which is currently susceptible against MitM attacks in future versions? For example, by using DHE/ECHE-PSK and exchanging a longer PSK or certificate in the established connection and limiting the number of failed connection attempts to a small number? The best solution would be to use PACE or another PAKE here, for secure coupling of UD and Remote-IFD based on low-entropy passphrases. Why aren't QR codes containing a sufficiently long PSK or certificate used here? Because of accesibility issues? |
|
@misery Do you need additional input/help on this? |
|
? |
|
We are waiting for an answer from the BSI. |
The Randomizer class provided an insecure mersenne twister PRNG as a convenience method to draw things like PINs and serial numbers from it.
I changed this to always use a secure OpenSSL-based CSPRNG.
Furthermore, the OpenSSL PRNG was insecurely seeded from the mersenne twister RNG. Fix this, by combining several input sources via a cryptographic hash function and seed OpenSSL from it.
Please note, that OpenSSL in typical configurations is automatically seeded and the seeding strategy here probably did no harm by accident in the past.