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