Re: [CryptoAPI-devel] musings...

[Herbert V. R. <hv...@hv...>]

hello!

On Sat, 2002-03-02 at 01:58, Kyle McMartin wrote:
> just a quick list of observations and/or stuff i've looked at:
=20
> - 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.
I was tented myself, but then decided, that it wasn't worth it for just
2 files... :-) or even just one file, since the wordops.h should really
go into asm... or into byteorder.h, as it's a generic algo...
=20
> - 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.
mmmh... I guess I should add you guys to the sf project sooner or
later... do you have any sf id yet? :)
=20
> - 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.
...which bug? (sorry, I don't know right now what you are referring
to... :-/)
=20
> - 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.
btw, that's something I've spent the last few hours with... and finally
also committed something to CVS about it... i.e. should be fixed :-)
=20
> - rewrote a bit of the Config.in's to make a bit more sense to a user.
great :-)
=20
> - 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>)
=20
> I have most of this locally, and will likely clean up the rest and send
> a patch for you to approve/disprove of.
ok... since I'm going to get some sleep now, you've got plenty of hours
to do that :-)
=20
> 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.
a few... i.e. yes, it would break them a bit :-)

oh.. and I guess I broke the API, by moving the IV argument back to a
2.4.3-patch-int compatible manner.... hope this was the last API
breakage...=20

> 2: defined as KDIR, going with current convention. best settable by
>    the user at `make' time.
btw, if you have any suggestions for how to improve the makefile
framework - just step forward! :-)

It was just a quick hack based on someone else's distro to get things
running; but for a release it's still far too unpolished....

regards,
--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142