[openssl-dev] Plea for a new public OpenSSL RNG API

[Dr. Matthias St. Pierre]

>     >  We have a similar situation, on a small hardware device with little own entropy
>     > but with a smartcard reader.
> 
> Yes, but in most cases you cannot count on the smartcard (or smartcard-like device) being in the reader.
> Which is why in my opinion this is an ideal case for “additional input” source, but rather poor as the
> “main” entropy source.
> 
> ...
> 
>    >  We implemented a get_entropy() call which fetches the entropy via PKCS#11, and
>    >  modified the rand_method such that RAND_DRBG_generate() is always called with
>    > prediction_resistance=1. So every generate() triggers a reseed(), the entropy is fetched
>    > from the smartcard and it is immediately postprocessed by the AES-CTR DRBG.
>    > The /dev/urandom device was only used as additional input.
>    > So we didn't feel the need for an extra API call.
> 
> I would do exactly the opposite. “Normal” entropy is fetched from the default sources (/dev/urandom). But
> when a sensitive (aka long-term) keys are generated, a (portable :) hardware RNG is plugged in and used with
> RAND_add() equivalent. Reason – in my setup reliable trusted hardware RNG is not always on. If it were, I’d
> use it as the main entropy source and be done with it.


In general, I would agree with you. In our case, it was a requirement of the government to trust only the SmartCard RNG. Since we use it for VPN connections with SmartCard authentication this was no problem, because the SmartCard must be present in order to initiate the IKEv2 exchange. The only tricky part was to deal with temporary failures of the entropy source.

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170830/97ac1c84/attachment.bin>