[Cryptography] OpenSSL and random

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sun Dec 4 02:19:04 EST 2016


Nico Williams <nico at cryptonector.com> writes:

>For a sufficiently-low number of bits we'd have a number of recognizable SSH
>host keys and such.  

That's a good point, but it's conflating entropy with randomisation.  To get
per-device unique keys, you don't need strong entropy, just a per-device
unique value to make sure you don't get repeats.  In fact, here's a magic
trick: A secure SSH key without needing any entropy! [0]

  seed = HMAC( fixed_secret, time() || MAC address || IP address || kernel version || ... );

>What I really want is an API that lets me specify my app's minimum entropy
>requirement, and returns an error if that minimum cannot be met.
>
>Two or three values will do: "meh" and "cryptographically-secure", or "meh",
>"low-value", and "high-value cryptographically-secure".  "Meh" would always
>be available.  A number of required bits of entropy will also do, but IMO
>it's overkill.

Yup, that's a good idea.  In fact I implement exactly that in my code, there's
a nonce RNG and a crypto RNG, and in most cases the nonce RNG gets called
because that's all that's needed.

Only downside is that you then need to educate users to only call the crypto
RNG when required.  This may be tricky, even crypto standards get this wrong.
For example every version of the SSL/TLS spec has required that the
client/server nonce be generated from a crypto RNG when what's needed is a
generic nonce RNG.  In fact using a crypto RNG is actively harmful since it
exposes your a considerable amount of your crypto RNG output (think EC-DRBG)
directly to an attacker.

Peter.

[0] Since entropy is defined relative to a source model, you can in theory
    claim almost anything has an entropy level ranging from zero to infinity.
    I'll avoid semantic tricks like that and define "entropy source" to mean
    some sort of strong physical randomness source, not necessarily
    radioactive decay or equivalent but things like packet jitter, interrupt
    timing skew, that sort of thing.


More information about the cryptography mailing list