In message <0e062727611c44bb8039170bbec11...@ex13.ncp.local> on Tue, 29 Aug 2017 13:05:21 +0000, "Dr. Matthias St. Pierre" <matthias.st.pie...@ncp-e.com> said:
Matthias.St.Pierre> > Frankly, I cannot see anything wrong with making that a public API. I Matthias.St.Pierre> > wonder, though, if this is going to be an implementation that's kinda Matthias.St.Pierre> > sorta built-in only, or if other implementations of the basic stuff Matthias.St.Pierre> > will be possible... or in other words, will we have a "method" Matthias.St.Pierre> > structure like we have with so many other APIs? In saying this, I'm Matthias.St.Pierre> > counting in the possibility that some implementations could come in Matthias.St.Pierre> > the form of engines, is this something that's been thought about? I Matthias.St.Pierre> > do notive the DRGB_CTX structure, but that doesn't quite follow the Matthias.St.Pierre> > usual "method" pattern we have... Matthias.St.Pierre> Matthias.St.Pierre> 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. Essentially, the argument for your last remark is in-structure vtable vs refered to vtable. I tend to prefer the latter (and that's the usual OpenSSL pattern too, even though there are exceptions). -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
