Schneier on Security

The question still remains:
Can Bruce Schneier design a cipher so secure that he cannot break it?

Bruce, this is quite a common problem with certification cycles. Do you have any suggestions to shorten certification cycles?

What's interesting to me in that article is the two major causes cited for the long validation. First, that the CMVP folks had to validate source instead of binaries (meaning, no doubt, trying every possible config option set). Second, that many people -- especially competitors -- made complaints in order to slow down the process.

The OpenSSL folks seem to have the right attitude about it, though:

"With other software [tested by CMVP], all the proprietary information is treated as trade secrets and we can't comment on it. On the one hand, that gives someone an advantage to disparage our work. On the other hand, we've been scrutinized and tested in the open, so we have a much more solid validation than the others."

To paraphrase Bruce Schneier, in \fIApplied Cryptography\fR, the reason certification takes so long is that \fBevery\fR possible set of options needs to be validated. If you have 20 independent, binary, options, you have 2^20 possible combinations(about 10^6).
This can be made smaller by making software simple.
``Complexity is the enemy of security''

It should be pointed out that normal certifications for FIPS compliance are quick (months, not years), as they test pre-compiled binaries against test vectors. OpenSSL took longer because they had to do it at the source code level. They did this because it is open source, and therefore impossible to verify every possible compiled version of the code on every supported platform and against every dependency combination.

See why proprietary code is better? It only takes months to certify it!

(Bill Gates laughs evilly)

It seems I'm developing a habit of putting security-related tidbits into the comments of whatever the most recent article in this blog is. Bruce, let me know if you think this is inappropriate.

Anyhow, back to the off-topic: New Scientist report an interesting anti-cellphone-theft measure. You need to enter a password every time put a number into the phone's memory, or anytime you call a number not in the phone's memory. This lets you use the phone without often needing to enter the password, but makes it essentially useless to anyone not in posession of the password.
http://www.newscientisttech.com/article/dn11212-invention-hot-lap-prevention.html
(third item. The second item is also security related.)

I've already thought of (and possibly suggested on this blog) a very similar scheme for online banking. Substitute "make a payment" for "make a call", "add an account to a white list" for "enter number into the phone's memory" and "turn up at a bank branch and sign papers" for "enter password." As such, I don't think this is worthy of a patent, but that is a different argument.

The comments are on an important point: the certification cycle for commercial software is much shorter. So while there is an interesting debate about whether the test cycle *needs* to be longer for source code, if this is fair, more thorough, etc. Bruce's high-level comment about software development cycles being faster than certification cycles is not accurate for commercial software. Speaking from the perspective of a commercial vendor who did not obstruct the OpenSSL validation.

So they could have provided binaries for (say) x86, PowerPC Linux and BSD, and had those quickly certified, had they wished to? (And encouraged OS vendors to submit an OpenSSL compiled against their OS?)

@Filias:
If you get the sources, to compile it yourself, you may fiddle around with all the compilerflags (optimize for 386, 486, 586, 686 ... for size, for speed, for a compromize, ...) include debug-information or not and so on.

A lot of 'monkey business' there.

"We called it the FUD campaign," he says. "There were all kinds of
complaints sent to the CMVP including one about 'Commie code.' .. Silly or
no, each complaint that's filed really slows down the process."

http://www.linux.com/article.pl?sid=07/02/08/1935232

"Can Bruce Schneier design a cipher so secure that he cannot break it?"

Yes, and he can design a cipher so secure that only he can break it as well :-)

@Filias Cupio

"I've already thought of (and possibly suggested on this blog) a very similar scheme for online banking. Substitute "make a payment" for "make a call", "add an account to a white list" for "enter number into the phone's memory" and "turn up at a bank branch and sign papers" for "enter password." As such, I don't think this is worthy of a patent, but that is a different argument."

I'm not sure about other countries, but this scheme is used for years in Poland by at least one bank. You can create "defined payment" (target account, amount, etc), which must be authorized by one time password (you are already logged in by SSL, of course). Once defined, you can make such payment by a single click (when you are logged in), but editing anything requires one time password.

Some of the comments above are misleading. Binary-only libraries are also inspected at the source level during 140-x validation, and open/free/source-available ones are also tested in binary form (eventually, after source reviews). 140-x testing formally covers only selected, well-defined configurations, even if the module may be configured. This restriction is enforced mainly for the benefit of end-users, who should be able to easily check whether they run a version that has been actually tested. The only important difference between source-available and closed-source products is how much of the support documentation becomes public. For binary-only apps, most documentation remains confidential between the vendor, test lab, and NIST.

Otherwise, part of the hurdles for Openssl were real and technical (incorrect module definition), which were corrected. The rest are described in quotes above. A comparable closed-source product, without the backstabbing, would have passed through the progress several times faster, but still possibly in more than a year. Some of the 140-x process is not technically challenging, just mandates things that are unusual in everyday development, and sorting those out (changing procedures etc) can take a while, even if it does not change technical content.

Otherwise, minor nitpick, which NIST insists on correcting: FIPS 140-x modules should not be called "certified", rather "validated". Even if there's a certificate issued in the end, the term is validation to avoid implying NIST endorses a module (somewhat related to `CYA' described in another blog entry).