On Sat, Aug 29, 2009 at 05:34:04PM -0400, Steve Marquess wrote: > > Long term what we'd really like to do is create a truly independent and > separate FIPS mode algorithm implementation in the form of a FIPS mode > ENGINE. That way the associated source distribution would contain only > relevant source code, and the "FIPS capable" OpenSSL distributions would > function entirely independently of the FIPS related code when not in > FIPS mode. The FIPS validated ENGINE implementation would also remain > usable with a wider range of subsequent OpenSSL releases.
That this wasn't the obvious approach from the very beginning speaks worlds about the limitations of the ENGINE interface. It is simply at the wrong level of abstraction to give good performance (or even full featured operation) with modern accellerators *or* to guarantee FIPS conformance if the library is actually to be used for SSL/TLS! For example, as it stands now no ENGINE can actually enforce the various special-cases about MD5 use in the KDF, and can't enforce the upcoming restrictions on SHA1 use, namely only within HMAC (well, possibly, by registering the HMAC nid but not the raw SHA1 one -- but I don't think that presently actually works). If the ENGINE interface were revised to actually match the way modern SSL accellerators work -- offering single operations which implement entire steps of the handshake and one-shot record encryption/decryption -- it would then be radically easier to produce a special FIPS engine which could be much more easily validated as implementing TLS in the right way. If the ENGINE interface were then left stable, that FIPS engine could be used with future versions of OpenSSL. This would also let vendors supply drop-in FIPS validated engines for their own validated hardware, which would be pretty neat. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
