Hi,

have you looked at http://libtomcrypt.org/? It comes with a license
as-is, and it suportes everything except C++ (it's a C - library).
Download size is 1.1 MB as zip file. Unpacked source is 3 MB.

Cypher size is:

du -hs src/ciphers/
628K src/ciphers/

It supports:
# Blowfish
# XTEA
# RC5
# RC6
# SAFER+
# Rijndael (aka AES)
# Twofish
# SAFER (K64, SK64, K128, SK128)
# RC2
# DES, 3DES
# CAST5
# Noekeon
# Skipjack
# Anubis (with optional tweak as proposed by the developers)
# Khazad

Chris

Am 07.04.2005 um 21:38 schrieb Jim Starkey:

>
> 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
> Netfrastructure, Inc.
> 978 526-1376
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>