On Mon December 22 2008, Steve Marquess wrote: > a_l t wrote: > > If I want to validate a stripped down module (let's say > > for simplicity just without the unwanted self tests), is there a fast > > way to do it, or I should expect a 6 months process? > > Six months would be fast. For uncomplicated validations I tell my > clients to hope for nine months but to be prepared for twelve or more. > There is not only a long lead time, but very little feedback on the > progress of the validation. That makes any product or project > deliverable involving a new validation a very chancy prospect. The > unpredictable time element is more of a disincentive to many vendors > than the cost which can also be considerable (many tens of thousands of > dollars). > > BTW if you drop algorithm self-tests you'll have to drop the algorithm > as well. > > > I also didn't quite understood what you meant in the last sentence: > > "Where FIPS validation is mandated operations considerations take second > > place." > > Sorry, typo. I meant "operational considerations". Kyle stated it well > already: you only want to use FIPS validated products where there is a > specific policy mandating such use, there is no other advantage -- they > aren't more secure or less expensive, performance is no better, > selection is limited and they can't be customized or adapted in any way. > In fact given the powerful disincentives to bug fixes it can be argued > that FIPS validated products are significantly *less* secure than their > non-validated equivalents. >
It is also possible that <a_l t> is looking at the wrong set of requirements. ;) For a hardware device with a dedicated purpose (which is what a DSP with FIPS firmware approved sounds like) - There are other requirement sets that would serve the purpose (sorry, I don't have current document numbers to quote) - In principle, it is a process to get the "complete device" validated for the use - what is inside the "complete device" that gets the job done doesn't count. ;) Only the protection from "undetected change" must be met. (The locked courier bag analogy - which is what the "self tests" of software achieve) But my real point in this post is the first line above. Reconsider the application and the various sets of requirements - you may be looking in the wrong manual. Mike > -Steve M. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
