>> > 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.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
