lkml.org 
[lkml]   [1998]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CIPE - Encrypted IP Encapsulation
On Tue, Aug 04, 1998 at 01:20:01PM +0200, Olaf Titz wrote:
> > I've been thinking about this lately. There are beginning to be quite
> > some crypto-patches to the kernel and to be more accessible and reduce
> > bloat (not duplicating DES 5 times), I think an up-to-date
> > "international version" of linux is needed, and a team to maintain it.
>
> First we'd need to agree on a crypto API. This could be as simple as
>
> int crypt_get_cipher(const char *name);
> /* e.g.: if ((hndl=crypt_get_cipher("blowfish"))<0) return hndl;
> will allocate space for the key, and return a handle to this
> cipher instance, <0 on error
> requests the proper cipher module
> */
> int crypt_key_setup(int hndl, const char *key);
> int crypt_encipher_stream(int hndl, const char *src, char *dest, size_t len);
> int crypt_decipher_stream(int hndl, const char *src, char *dest, size_t len);
> int crypt_encipher_ecb(int hndl, const char *src, char *dest);
> int crypt_decipher_ecb(int hndl, const char *src, char *dest);
> int crypt_encipher_cbc(int hndl, const char *src, char *dest, size_t len, const char *iv);
> int crypt_decipher_cbc(int hndl, const char *src, char *dest, size_t len, const char *iv);
>

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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.079 / U:0.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site