[CryptoAPI-devel] musings...

[Kyle M. <ky...@de...>]

just a quick list of observations and/or stuff i've looked at:

- locally, i have moved include/linux/{crypto,wordops}.h to
include/linux/crypto/{crypto,wordops}.h, [1] i suspect this to be
a better convention, since it makes copying things in and out
of the kernel source directory easier.

- rewrote a chunk of the top level Makefile, we now have copy-files,
which shoves cryptoapi into the kernel [2] patch-kernel, which
applies the patch in the top level kernel dir, and unpatch-kernel,
which reverses the patch. based on dbryson's idea.

- looked into the rc5 "bug" and the rc5 paper by rivest. i can see
the problem, but am agast at how to attack it properly, as it seems
(from the paper) that the value of "c" is needed later. i assume
this is because the key is stored in a c-element array.

- looked into the blowfish bug, based on mailing list messages it
seems that this is due to it being handled little-endian, and
blowfish being specified as using big-endian in memory.

- rewrote a bit of the Config.in's to make a bit more sense to a user.

- moved the MODULE_* definitions out of the ciphers, and into an
#ifdef MODULE inside of crypto.h, since alot of the kernel stuff is
already there. some ciphers didn't have a license and modinfo stuff,
so i figured i would kill the flock of birds with one stone. (i set
the author to the Linux Kernel Crypto Team <this mailing list>)

I have most of this locally, and will likely clean up the rest and send
a patch for you to approve/disprove of.

1: is this alright? i'm not sure how many applications are actually
   using cryptoAPI, regardless, i have a simple shell script to
   recursively handle it.
2: defined as KDIR, going with current convention. best settable by
   the user at `make' time.

  - k
-- 
copyleft (c) 2002, Kyle McMartin