| Abstract | In this work we demonstrate various weaknesses of the random number generator (RNG) in the OpenSSL cryptographic library. We
show how OpenSSL’s RNG, knowingly in a low entropy state, potentially
leaks low entropy secrets in its output, which were never intentionally
fed to the RNG by client code, thus posing vulnerabilities even when in
the given usage scenario the low entropy state is respected by the client
application. Turning to the core cryptographic functionality of the RNG,
we show how OpenSSL’s functionality for adding entropy to the RNG
state fails to be effectively a mixing function. If an initial low entropy
state of the RNG was falsely presumed to have 256 bits of entropy based
on wrong entropy estimations, this causes attempts to recover from this
state to succeed only in long term but to fail in short term. As a result,
the entropy level of generated cryptographic keys can be limited to 80
bits, even though thousands of bits of entropy might have been fed to
the RNG state previously. In the same scenario, we demonstrate an attack recovering the RNG state from later output with an off-line effort
between 282 and 284 hash evaluations, for seeds with an entropy level
n above 160 bits. We also show that seed data with an entropy of 160
bits, fed into the RNG, under certain circumstances, might be recovered from its output with an effort of 282 hash evaluations. These results
are highly relevant for embedded systems that fail to provide sufficient
entropy through their operating system RNG at boot time and rely on
subsequent reseeding of the OpenSSL RNG. Furthermore, we identify a
design flaw that limits the entropy of the RNG’s output to 240 bits in
the general case even for an initially correctly seeded RNG, despite the
fact that a security level of 256 bits is intended. |
|---|
