Re: Plea for a new public OpenSSL RNG API

    >> >   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.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev