On Mon, Jun 18, 2012 at 11:58:56AM -0700, Kyle Hamilton wrote: > So what can we do to solve it? Create our own "reputable review" service? > > Who would pay for it? Who could pay for it? Who *should* pay for it?
At first it seems like irony that buyer-pays is likely the process best aligned with the buyers interests and yet most people are willing to pay very little if anything for additional security, and organizations typically will only pay for as much as (and exactly in the form that) their regulator requires. Likely this suggests something about the true nature of the interests of the market. :) Maybe there is room for a Consumer Reports/Cooks Illustrated-style review model, which does have the advantage of spreading the review costs over many buyers. I don't know of any attempts like this though. > Given that the penalty for an individual who works at a US Federal > contractor on a US Federal contract who is found to have skimped on > quality control is pretty much a 20-year guaranteed felony > imprisonment, I have more faith in the CMVP than you appear to. I've never heard about someone trying to talk past, say, an AES implementation that didn't actually work, or a bad RSA, that's a pretty bright line. In that sense, FIPS is very good for setting a minimum bar, ensuring that the system is not completely screwed up. However because most attacks can either be ignored or specificationed around in the security policy or by shooting for a lower level of validation, FIPS 140 is not very good at producing a product which can protect against a determined attacker [1]. The tests are mostly affirmatives 'does it work', not 'how can I cause this to break'. > Also, CMVP-validated and NIST-certified modules which implement Suite > B (ECC and AES) are permitted to protect US national secrets up to > "Secret" level. I don't think NSA is going to let that happen with > modules it lets the military and its contractors use. I agree this is the case, but I would also guess that NSA has its own review process for this. For instance, FIPS 140 says nothing about cache or timing attack countermeasures [2], which are pretty relevant for AES and ECC and which I would hope (!) the NSA would bake into its own procurement processes and in what it recommends or requires DoD contractors to use. (I would be interested if anyone knows the details of this, though). -Jack [1] Note that I am not saying that FIPS certified products intrinsically cannot protect against determined attackers, just that it is likely that any product which could do so likely did it without much help from the FIPS review process. [2] OK I just checked, the FIPS 140-3 draft does finally require countermeasures against DPA and timing attacks for level 3+ hardware evals. No such requirements for software though. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
