[Cryptography Team] msh-crypto design and tests

[Matthew S. Hamrick]

Hey everybody...

Way back in the olden days I was part of the team at RSA that  
implemented J/SAFE (now called BSAFE Crypto-J.) One of the things we  
learned there was how important testing is. One of RSA's great bits  
of technology was the BTEST infrastructure. It was a series of tests  
that exercised the crypto primitives in BSAFE, ensuring that the  
implementation matched the published algorithms.

For a long time these tests were buried inside the deep recesses of  
RSA's engineering labs in Redwood City (later San Mateo) California.  
But then one day RSA wanted to move a lot of their development  
overseas to Australia. The idea was that most of their new customers  
were in Japan and Australia was close to being in the same time zone  
which made support a lot easier. Plus, the Aussies would work for a  
lot less than their bay area counterparts. The fact that Eric A.  
Young, the godfather of OpenSSL, was in .au only made things better  
(he wrote the first code that would implement the API popularized by  
OpenSSL.)

But they were faced with a problem, exporting their code to Australia  
was "difficult" under the existing export regulations. If you wanted  
to export a commercial crypto package, you had to jump through a lot  
of hoops; even if you were exporting things to a friendly place like  
Australia (I suppose someone was still worried that a communist  
insurrection could occur while we weren't looking.) However... this  
was not the case for documentation. If you wanted to type up a  
description of an algorithm or even a C implementation and publish  
it, this was okay. The law considered this to be contributing to  
international research efforts, not trafficking in controlled munitions.

Industry watchers believe RSA was planning on re-implementing their  
Crypto libraries overseas to make it easier for them to fit on 16 bit  
mobile phones, so the only thing they were worrying about was the  
API. They wanted to make sure that their overseas customers had the  
same API (or a similar API) as BSAFE.

The solution was pretty cool; they wrote a document that described  
the API in english text. But the text was regular enough that one  
could write a program to reconstruct the API from the english   
description of it. Pretty cool, huh?

This document was published as a IETF internet draft and thus avoided  
the export regulations... It wasn't code, it was a description of an  
interface published by a well regarded organization involved in the  
development of the internet.

So assuming you're not completely bored by this narrative, one of the  
very cool things that went with the API were the test suites. The  
test suites use industry recognized test vectors for ciphers and  
formats supported by the BSAFE library. In theory, it should be a  
trivial matter to write code to convert the document describing the  
test suites into SUnit tests.

So... assuming we want to do "Test Driven Development," there might  
be some advantage to having a large pool of test vectors,  
irrespective of where they come from. If there's interest in this  
group, I'll move the SUnit tests a little higher in the priority queue.

Also... there are existing test vectors in SUnit tests for msh-crypto  
that derive from the NIST documents and IETF RFCs. Even if you didn't  
want to use the msh-crypto implementation for license reasons, the  
SUnit tests could still be of value.

(BTW... msh-crypto is distributed under a BSD license to make it  
usable with Spoon without having to wring ones hands repeatedly about  
licensing issues.)

-Cheers
-Matt H.