Yes something like that. I was actually thinking of using SSLeay. It
is well maintained and compatible with user-land. It makes bug and
code-sharing trivial, and it is much like what you describe above.
One problem with SSLeay (and libdes,libcast,libidea,libbf) is that
they are not GPLed and they can not be put under the GPL according to
the license (which is BSD-like) [ however, the freeswan project
already uses libdes so this can't be a new problem ]. If the license
presents problems, we can always reimplement the crypto-api functions,
but we will still be compatible with SSLeay and that is useful in the
long run anyway. By using the library as a start, we don't have to
wait for this part of the infrastructure to be available.
The API is described in the docs/cipher.doc file in the distribution.
Short summary:
Per cipher information:
typedef struct pem_cipher_st
{
int type;
int block_size;
int key_len;
int iv_len;
void (*enc_init)(); /* init for encryption */
void (*dec_init)(); /* init for decryption */
void (*do_cipher)(); /* encrypt data */
} EVP_CIPHER;
"type" maps to an object which gives the name of the cipher
Some more random text from the documentation:
--cut--
EVP_CIPHER *EVP_des_ecb(); /* DES in ecb mode, iv=0, block=8, key= 8 */
EVP_CIPHER *EVP_des_ede(); /* DES in ecb ede mode, iv=0, block=8, key=16 */
EVP_CIPHER *EVP_des_ede3(); /* DES in ecb ede mode, iv=0, block=8, key=24 */
EVP_CIPHER *EVP_des_cfb(); /* DES in cfb mode, iv=8, block=1, key= 8 */
EVP_CIPHER *EVP_des_ede_cfb(); /* DES in ede cfb mode, iv=8, block=1, key=16 */
EVP_CIPHER *EVP_des_ede3_cfb();/* DES in ede cfb mode, iv=8, block=1, key=24 */
EVP_CIPHER *EVP_des_ofb(); /* DES in ofb mode, iv=8, block=1, key= 8 */
EVP_CIPHER *EVP_des_ede_ofb(); /* DES in ede ofb mode, iv=8, block=1, key=16 */
EVP_CIPHER *EVP_des_ede3_ofb();/* DES in ede ofb mode, iv=8, block=1, key=24 */
EVP_CIPHER *EVP_des_cbc(); /* DES in cbc mode, iv=8, block=8, key= 8 */
EVP_CIPHER *EVP_des_ede_cbc(); /* DES in cbc ede mode, iv=8, block=8, key=16 */
EVP_CIPHER *EVP_des_ede3_cbc();/* DES in cbc ede mode, iv=8, block=8, key=24 */
EVP_CIPHER *EVP_desx_cbc(); /* DES in desx cbc mode,iv=8, block=8, key=24 */
...
EVP_CIPHER *EVP_bf_cbc(); /* Blowfish in cbc mode,iv=8, block=8, key=16 */
The meaning of the compound names is as follows.
des The base cipher is DES.
idea The base cipher is IDEA
rc4 The base cipher is RC4-128
rc2 The base cipher is RC2-128
ecb Electronic Code Book form of the cipher.
cbc Cipher Block Chaining form of the cipher.
cfb 64 bit Cipher Feedback form of the cipher.
ofb 64 bit Output Feedback form of the cipher.
ede The cipher is used in Encrypt, Decrypt, Encrypt mode. The first
and last keys are the same.
ede3 The cipher is used in Encrypt, Decrypt, Encrypt mode.
All the Cipher routines take a EVP_CIPHER_CTX pointer as an argument.
The state of the cipher is kept in this structure.
typedef struct EVP_CIPHER_Ctx_st
{
EVP_CIPHER *cipher;
int encrypt; /* encrypt or decrypt */
int buf_len; /* number we have left */
unsigned char buf[8];
union {
.... /* cipher specific stuff */
} c;
} EVP_CIPHER_CTX;
...
--cut--
>
> > The important part of this is to get the infrastructure right. A
> > patch distributed "together" with the normal kernel would be immensely
> > more useful than an obscure patch distributed from some far-away
> > place. What I was thinking was to make a primary international site
> > that mirrors ftp.kernel.org an "overlays" a patch-crypto-x.y.z.gz file
> > in the v2.{0,1} catalogs. This is not a new idea, but similar to the
>
> The actual patch should be small enough to just add the necessary
> hooks into the loopback device, networking etc. I'd prefer to make
> modules out of the rest if possible.
>
Yes the patch should be as small as possible, and I think a design
rule should be that there are no side-effects to the patch. That
means that all patches to files from the vanilla kernel should be
protected by CONFIG_XXX flags. This makes it possible to say to
people "recompile without CONFIG_INTERNATIONAL" and the resultant
behaviour would be identical to the vanilla linux kernel.
However, even if the patch is kept small, I think it is inevitable
that it includes for example tcfs. I don't think tcfs can be split up
into a vanilla kernel-part and a "crypto-part". I think tcfs will be
considered to be crypto-software or full of crypto-hooks no matter
what you do to it.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html