[openssl-dev] Plea for a new public OpenSSL RNG API
Blumenthal, Uri - 0553 - MITLL
uri at ll.mit.edu
Wed Aug 30 14:49:57 UTC 2017
>> > It allows hardware sources to be used via the same API.
>>
>> I rather doubt this. For example, my smartcard (accessible via PKCS#11) is a hardware source, which I
>> occasionally use. How do you see it used with the same API?
>
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170830/2c3fd156/attachment.bin>
More information about the openssl-dev
mailing list