On Apr 7, 2005 10:38 PM, Jim Starkey <jas@...> wrote:

>
> 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
>
> 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?

there is already nss Network Security Services from mozilla project
and is under Mozilla Public License
Don't know if that helps you ...

"You can use NSS to support a range of security standards in your
application, including the following:
....
AES, RSA, DSA, Triple DES, DES, Diffie-Hellman, RC2, RC4, SHA-1, MD2,
MD5: Common cryptographic algorithms used in public-key and
symmetric-key cryptography."

http://www.mozilla.org/projects/security/pki/nss/overview.html

--
developer flamerobin.org