A few months back we had a long discussion of what crypto libraries to
use. Mr. O'Donahue was arguing for SSL, I was pushing Crypto++ 4.2, and
others were mentioned.
Crypto 4.2, it turns out, neither compiles nor runs on AMD64. Current
version, 5.2.1, supports AMD64, but has grown enormously, and for all
practical purposes, is no longer subsettable. My interest has been
exclusively with DES, SHA-1, and RSA, though I expect to phase out DES
in favor of AES in the distant future. After weeks of head bashing, I
have come to the conclusion that Crypto++ and I are going separate ways.
I've been looking at crypto packages for a couple of weeks now. I'm
looking for a subsettable crypto package. The requirements are:
1. Compatible license (BSD, Mozilla, or equivalent)
2. C++
3. Subsettable
4. Support for RSA, DES, SHA, and AES
I haven't found anything that meets all requirements. To be frank,
Crypto++ comes closest, but the smallest subset blew my rpm from 3 MB to
14 MB, requires special switches to extend the internal space in the
Microsoft C++ compiler, and brings so much extraneous classes that the
original project gets lost in Visual Studio.
The basic problem is modularity. RSA, has two functions, public key
encryption and digital signatures. Digital signatures require a hash
(the signiture, not unreasonably, specifies the hash), which tends to
suck in SHA, MD2, MD5, RC4, and who knows what else. Those guys
invariable pull in x509 certificate stuff that drag in virtually
everything else in the crypto world.
A little research has shown that almost all free crypto code goes back
to SSLeay written by Eric Young. SSLeay is the foundation of OpenSSL
The license requires that you give Eric Young credit in your
documentation and that you not release the source under another license,
especially GPL. Much or most of the code in Crypto++, in fact, comes
from SSLeay. The downside of SSLeay is that it is written in relative
primitive C and anything sucks in just about everything.
Unless somebody knows of a package that has escaped my attention, I
think the acceptable solution is to do yet another free packagin of
SSLeay. I think the best way to attack the problem is:
1. Define abstract classes for each class crypto algorithm: Symmetic
block cipher, asymmetric block cipher, and hash.
2. Define a set of classes that civilize block transformations into
buffered transformations and implement "modes"
3. Implement simple primitive classes for each algorithm
4. Implement higher level classes to handle things like digital
signatures.
The key is to build the thing in layers so you can get at RSA for
session key exchange without bring into all of digitial signatures and
x509 certificates.
Since Eric Young has taken the step of putting his code in the public
domain unencumbered, I'm planning to do the same. There are two ways I
can go. I can do it myself and make it available when I'm done, or if
there is interest, run this as an informal open source project from
Netfrastructure CVS server.
Anyone interested?
--
Jim Starkey
