> Hi Steve, > > Thanks for the fast reply. So it sounds like I should discuss this > with the test lab with which we're working to see what they say. > > My time working in OpenSSL can still be counted in weeks, so I'd be > very interested in your opinion on this. Either way, it'll help me in > proceeding with this technically, help me in discussing this with the > test lab, or both. A few weeks ago, when I first joined this team, I > sat in on a gap analysis meeting with the test lab and I do recall > something about a hybrid solution being discussed. I'm going to read > 140-2 again now, specifically looking for discussion of hybrid solutions. > > From a technical perspective, is moving the cipher logic of the AESNI > engine over into fipscanister.o even feasible? I'm still a bit > confused on the difference between dynamic engines, static engines, > and builtin engines and have not yet come across documentation > explaining this.
Not such a fast reply this time... It is my considered opinion that AES-NI should not be treated as a "hybrid" module, and one test lab at least tentatively agrees. However, as always the FIPS 140-2 scripture and established formal interpretations lag behind the state of the technology. From an informal survey I get the sense that not all test labs would immediately agree with that assessment. In terms of scripture section 1.9 of the Implementation Guidance document is probably most significant, and interpretation will hinge on the term "disjoint": "... a special type of software or firmware cryptographic module that, as part of ... its composition, utilizes disjoint special purpose cryptographic hardware components ... [e.g. cryptographic hardware accelerator cards, cryptographic hardware chip(s)...]" To slightly oversimplify, I would take the position that if you can't disconnect a "component" with a screwdriver or soldering iron it isn't "disjoint"; to argue otherwise sets you down a slippery slope with many modern processors and would effectively prevent validation of much high performance cryptography. Inlining the AES-NI code is not something we'd normally care to do, but it is a reasonable response given the peculiar restrictions imposed by FIPS 140-2. That is our plan for supporting it in our upcoming open source validation, should we find a sponsor interested in support the inclusion of that platform. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
