On Thursday 11 December 2008 10:52:36 Thor Lancelot Simon wrote: > On Thu, Dec 11, 2008 at 10:03:32AM -0500, Geoff Thorpe wrote: > > Engines like eng_cryptodev.c *are* built in (they're in > > ./crypto/engine/ rather ./engines/) and the intention is that they > > should be the implementation "de base" for those build targets to > > which they apply. > > I'm surprised this can be certified for FIPS. Are you sure it is the > case for the FIPS module? > > Consider that eng_cryptodev will in many cases end up using unknown -- > and thus presumptively unvalidated -- hardware implementations of most > of the core algorithms, in some cases even software implementations in > the kernel. > > I would be surprised that the test lab would allow 'hooks' like this > in the FIPS module.
I'm not saying they did, do, would, nor should. But your point about unvalidated hardware implementations would equally cover the alternative intel code-path, just as it would(/might/could/has) cover(ed) the via-padlock code-path. The engine issue is about how the C code is laid out, not about what was, is, or should be validated, nor is it *necessarily* about what is static versus dynamic. My point is that there's zero technical argument for bypassing a mechanism whose sole purpose is to organise algorithm implementations, so that one can instead directly hack/patch a pre-existing implementation. If the engine mechanism needs work to meet or beat requirements, that's where the effort should go. Andy can speak for himself, but I *think* that was his point too. Caveat: I haven't been involved in FIPS at all BTW, so I find myself in the "couldn't care less" category regarding the details. But if there's something that needs to be locked down (ie. fixed in the C code), we can surely lock it down as a part *of* the engine code rather than locking out engine code altogether. If this isn't the case then long-term, FIPS work will diverge significantly from (a) ongoing development, and (b) common sense. Side-note: I've heard people who *are* involved in the FIPS work speak of it in fairly colourful ways - I suspect they'd agree that the "standard" (and its process) is little more than bureaucratic, superstitious B-S. IANAL, FWIW, etc. :-) Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
