lkml.org 
[lkml]   [1997]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Crypto] Re: ftp.kernel.org vs. ftp.funet.fi
Date
From
> to export it, or he will be a felon).  As this is the case, I doubt that 
> real crypto will be in the official distribution of the kernel anytime in
> the near future.

We should specify an interface with which a loadable module, developed
outside the U.S., could provide crypto functions, and other modules or
parts of the kernel could elect to use them if available. The
interface should be generic enough to not specialize on crypto stuff,
so we don't make the same mistake as the Kerberos people.

E.g. something like this in the kernel:

typedef int (*transfunc)(const char *src, int len, char *dst);

struct transform {
struct transform *next;
char name[8];
transfunc setup, trans1, trans2;
}

int register_transform(struct transform *trans);

and a Blowfish module could then have something like:

int bf_setup(const char *userkey, int userkeylen, char *key);
int bf_encr(const char *key, int plainlen, char *plain);
int bf_decr(const char *key, int cryptlen, char *crypt);
/* doing en/decryption in place */
struct transform bf_transform = { NULL, "BF", bf_setup, bf_encr, bf_decr };

Modules using crypto functions could check in the list of "transform"
structures if their desired algorithm is available and act
accordingly. (e.g. the loop device)

Of course this has to be worked out in detail, but the general idea
should be obvious: have a means of registering and accessing functions
that transform data blocks. (This could be used for non-crypto
purposes as well.)

olaf

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