Re: Plea for a new public OpenSSL RNG API

> If I understand correctly, the RAND_DRBG API is really a completely
> separate API that has nothing to do with the RAND_METHOD API pers se,
> i.e. any association between the two is more or less "accidental"?

Yes, you're right. The original DRBG API was implemented for the FIPS object module (only) by Stephen Henson. A FIPS capable libcrypto 1.0.2y implements a binding from RAND_METHOD to the FIPS DRBG, FIPS_drbg_method(), which becomes the default RAND_METHOD when FIPS mode is enabled. So this was how the FIPS DRBG was 'plugged in' at runtime. *Note*: In those days, the FIPS DRBG pulled its entropy using the (non-fips) RAND_SSLeay() method, which was seeded using RAND_poll()/RAND_add(). Alltogether a really weird construction.

> Frankly, I cannot see anything wrong with making that a public API.  I
> wonder, though, if this is going to be an implementation that's kinda
> sorta built-in only, or if other implementations of the basic stuff
> will be possible...  or in other words, will we have a "method"
> structure like we have with so many other APIs?  In saying this, I'm
> counting in the possibility that some implementations could come in
> the form of engines, is this something that's been thought about?  I
> do notive the DRGB_CTX structure, but that doesn't quite follow the
> usual "method" pattern we have...

Currently it's only possible to customize the callbacks but not the deterministic algorithm. IMHO this is sufficient for the needs of a standard OpenSSL user who only wants control over the entropy source. A true new algorithm (like e.g. CHACHA2_DRBG) should be implemented by experts and added mainstream. So I don't see any advantage of having an engine over using the 'vtable' approach from the FIPS DRBG, which has been removed.


Regards,
Matthias

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