Menu
▾
▴
cryptoapi-devel — internal mailing list for developers only
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(16) |
Mar
(71) |
Apr
(28) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Kyle M. <ky...@de...> - 2002-03-02 03:01:25
|
On Sat, Mar 02, 2002 at 02:53:41AM +0100, Herbert Valerio Riedel wrote: > hello! > > 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... > nod. i do think it would be a bit better convention though. since if it gets merged into the kernel it will find a nice place in /usr/include. this also follows the generic bsd convention for crypto. whatever you wish though, since one file is just as easy. > mmmh... I guess I should add you guys to the sf project sooner or > later... do you have any sf id yet? :) > yeah, kmc...@us... > ...which bug? (sorry, I don't know right now what you are referring > to... :-/) > it's included in the blowfish bug report. has to do with the "c" for the cipher being for only 256bit. > 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 :-) > excellent! > ok... since I'm going to get some sleep now, you've got plenty of hours > to do that :-) > righty-oh. > > 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 :-) > I shall leave it then. > > 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.... > sure thing. i'm trying to work out a way to easily determine the kernel version. i think i'm going to have to fall back to frobbing the top level kernel Makefile. g'night, kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-02 01:53:52
|
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
|
|
From: Herbert V. R. <hv...@hv...> - 2002-03-02 01:51:51
|
On Sat, 2002-03-02 at 02:40, Mark Cooke wrote: > Thanks for the draft - I've just pulled it home to read. btw, it's not polished up yet - it's WIP; I hope it the packaging is self-explaining... =20 > A few more datapoints on cipe + cryptoapi: =20 > I upgraded Machine A to the 2.4.18-ac1 + crypto + cipe + iv-diff. >=20 > Tried aes-cbc, dummy-cbc and the default internal cipe-blowfish, and > all fail with a 'cipc0: decrypt CRC error'. (Machine A and B are both > x86, so it shouldn't be endian-things) >=20 > I've looked quite hard at the _encode and _decode calls but everything=20 > seems to match up in terms of moving around points to account for IVs=20 > being prepended. btw the changes I did, were mainly to revert to the old API as of patch-int-2.4.3, so that the weird version-dependent patch (which is doomed to break, once cryptapi gets version indepent) I saw for CIPE should become unecessary...=20 applications which need to re-entrantly encrypt data w/ the same cipher context should use the new _iv variants (which correspond to the crypto patches > 2.4.3 and <=3D 2.4.18.0) which pass the iv as arg pointer 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 |
|
From: Kyle M. <ky...@de...> - 2002-03-02 00:57:58
|
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
|
|
From: David B. <db...@du...> - 2002-03-01 20:49:42
|
Oops! forgot to send this to the list... -----Forwarded Message----- From: David Bryson <db...@du...> To: Herbert Valerio Riedel <hv...@hv...> Subject: Re: [CryptoAPI-devel] check it out... Date: 01 Mar 2002 13:10:43 -0700 Ask and ye shall receive: Here is a patch to do kernel patching in the makefile. I'm not sure that it does everything you wanted.. i hard coded it to do only the 2.4 series patches, but i assume we can change that. And i wasn't sure where the loop stuff was in the sources.. so i didn't add that. There is a make patch-kernel and a make unpatch-kernel i *think* did the diff right, lemme know if i didn't. Dave On Thu, 2002-02-28 at 10:08, Herbert Valerio Riedel wrote: > > I've done some more work on the Makefile system; > > please checkout the cryptoapi-new module (you need to remove it, and > re-checkout it, since I changed the CVSROOT/modules definition for > it...) > > the cool thing know is, that it gets the kernel parameters w/o having to > do a ./configure run... it's similiar to loop-AES' approach, but I've > stolen it from some other package :-) > > the next thing that's missing now, is some clever scripting, to > implement a > > "make patch-kernel" thingie... > > which basically > 1. copies the files from kernel/ into /usr/src/linux > 2. applies the correct patch/linux-2.4/kbuild-2.4.x file to > /usr/src/linux > 3. optionally patches /usr/src/linux/drivers/block/loop.c and loop.h > > > regards, > -- > 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 ---- ? crypto-kernelpatch.patch Index: Makefile =================================================================== RCS file: /cvsroot/cryptoapi/cryptoapi2/Makefile,v retrieving revision 1.3 diff -r1.3 Makefile 5a6,8 > # version number of kernel sources > KVER := 2.4.18 > 41a45,54 > > patch-kernel: > cp -r kernel/crypto $(KDIR)/kernel > cp -r kernel/include $(KDIR)/kernel > patch -d /usr/src -p0 < patches/linux-2.4/kbuild-$(KVER) > > unpatch-kernel: > rm -rf $(KDIR)/kernel/crypto > rm -rf $(KDIR)/kernel/include > patch -d /usr/src -R -p0 < patches/linux-2.4/kbuild-$(KVER) |
|
From: David B. <db...@du...> - 2002-03-01 20:48:28
|
So turns out the kbuild-2.4.18 patch was still setting the crypto Config's in /crypto, but the sources got moved to /kernel/crypto and so patching things broke all the configs. Especially menuconfig, it just wouldn't display anything. So i went through and changed them all to /kernel/crypto i just compiled a kernel with it and it appears to patch correctly, works well with the makefile patch i just submitted. Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-28 17:08:41
|
I've done some more work on the Makefile system;=20 please checkout the cryptoapi-new module (you need to remove it, and re-checkout it, since I changed the CVSROOT/modules definition for it...) the cool thing know is, that it gets the kernel parameters w/o having to do a ./configure run... it's similiar to loop-AES' approach, but I've stolen it from some other package :-) the next thing that's missing now, is some clever scripting, to implement a "make patch-kernel" thingie... which basically=20 1. copies the files from kernel/ into /usr/src/linux 2. applies the correct patch/linux-2.4/kbuild-2.4.x file to /usr/src/linux 3. optionally patches /usr/src/linux/drivers/block/loop.c and loop.h 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 |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-28 09:13:04
|
On Thu, 2002-02-28 at 07:15, David Bryson wrote: > I noticed that in the move to the new module the TODO, was missing.=20 > That may have been intentional ;-) but i'm not sure. So at any rate I > thought i'd ask which ones of these were still needed: thx for the reminder! :-) > TODO list > ~~~~~~~~~ >=20 > short term: >=20 > *) fix items listed in file BUGS and find new ones (without introducing=20 > them... ;-) ...this is an endless iteration :-) =20 > *) support for monolithic kernels (i.e. non-modular cryptoapi) btw, that should be easier know... the general procedure now is, to copy/symlink the content of cryptoapi-core into your kernel source... and then apply some kernel-version specific patch (i.e. the part of the latest patch-int on kernel.org, except for the files contained in Documentation/ and crypto/=20 oh, btw, this reminds me to create a cryptoapi-documentation module... > *) verify ciphers against known test vectors > (especially non-AES ciphers) that's still needed... I just found some blowfish test vector... but that's it... =20 > *) user space tool for converting encrypted volumes between different=20 > IV blocksizes, passphrases, key lengths, ciphers... > (tests/cvt_crypt.c) that's not so important right now; people can convert their encrypted space=20 =20 > *) check for byte order portability issues=20 btw, the blowfish cipher is such a known issue... see also jari's last mail... =20 > *) support 2.2.x kernel eventually it's getting less important every day... but it should be easy, given the self-contained crypto subdir... =20 > long term: >=20 > *) user space library containing ciphers and cryptoapi not so important, but nice to have =20 > *) improve API design yes... > *) in-place encryption that's actually auditing the code, to check whether all ciphers support this mode... i.e. checking whether src =3D=3D dst yields something non-corrupted... =20 > *) swap space encryption yeah, that's a personal favorite; I really like the openbsd paper, although I would start with a somewhat simpler (read weaker) key-management to get something at all working... ...any volunteers for a VM-swap implementation? > --------------------------- > I believe that it already has monolithic kernel support, but please > correct me if i'm wrong. I finally have gotten a chance to poke around it always had monolithic support :-) what I mean is, easy support for it... i.e. some semi-automatic way would be prefered... > the sources(eek gnu indentation =3D=3D evil, we should be using 1TBS) and > it's all very exciting stuff ;-) well, indentation should be our least concern... but if it helps development I don't have major problems with another indentation style... what's 1TBS btw? :-) 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 |
|
From: David B. <db...@du...> - 2002-02-28 06:16:59
|
I noticed that in the move to the new module the TODO, was missing.=20 That may have been intentional ;-) but i'm not sure. So at any rate I thought i'd ask which ones of these were still needed: TODO list ~~~~~~~~~ short term: *) fix items listed in file BUGS and find new ones (without introducing=20 them... ;-) *) support for monolithic kernels (i.e. non-modular cryptoapi) *) verify ciphers against known test vectors (especially non-AES ciphers) *) user space tool for converting encrypted volumes between different=20 IV blocksizes, passphrases, key lengths, ciphers... (tests/cvt_crypt.c) *) check for byte order portability issues=20 *) support 2.2.x kernel eventually long term: *) user space library containing ciphers and cryptoapi *) improve API design *) in-place encryption *) swap space encryption --------------------------- I believe that it already has monolithic kernel support, but please correct me if i'm wrong. I finally have gotten a chance to poke around the sources(eek gnu indentation =3D=3D evil, we should be using 1TBS) and it's all very exciting stuff ;-) Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-27 00:45:21
|
just fyi, I've uploaded an actualized version to ftp.kernel.org into the usual /linux/kernel/crypto/2.4/testing/ dir... it should match the CVS' content... 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 |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-27 00:12:34
|
On Tue, 2002-02-26 at 07:20, David Bryson wrote: > So do we want to stick to stablizing the 2.4.17 branch ? or is the > thought that we move with kernel releases ? I'm decompressing 2.4.17 > currently on my new box(hurray!) which i will use for cryptoAPI devel > and i'm about to pull CVS so hopefully I can get up to speed with the > both of you soon. well, I'd suggest to jump directly to the 2.4.18 kernel version as common grounds... (not that it would change anything... since as already said, the code itself is version indepentent, it's just the build-framework which needs little adjustments sometimes... btw, I've created a new module named 'cryptoapi-new' please check it out... you have to always use the toplevel Makefile... 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 |
|
From: David B. <db...@du...> - 2002-02-26 06:21:49
|
So do we want to stick to stablizing the 2.4.17 branch ? or is the thought that we move with kernel releases ? I'm decompressing 2.4.17 currently on my new box(hurray!) which i will use for cryptoAPI devel and i'm about to pull CVS so hopefully I can get up to speed with the both of you soon. Dave On Mon, 2002-02-25 at 19:50, Kyle McMartin wrote: > On Mon, Feb 25, 2002 at 10:54:19AM +0100, Herbert Valerio Riedel wrote: > > well... the cryptoapi in it's current form should be version > > independent! :-) > >=20 > Indeed, if this can be accomplished, it is indeed good. >=20 > > actually there's no sense for the tarball distro to carry a kernel > > version number... only for the kernel patch distro... > >=20 > > the only annoying stuff that changes a bit is the top-level Makefile, > > and some other minor bits in the build framework... > > > This will all stabilize... eventually, I guess it isn't really an issue > with judicious shell scripting. >=20 > > btw, so far the USAGI and a NFSv4 project is already using the > > cryptoapi; > > the frees/wan people are thinking about using it, but are a bit > > disappointed about the current status... > > =20 > FreeS/WAN also seems to be in the middle of a complete re-design, so > compounding their troubles might not go over well :> >=20 > regards, > kyle > --=20 > copyleft (c) 2002, Kyle McMartin >=20 > _______________________________________________ > CryptoAPI-devel mailing list > Cry...@li... > https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel |
|
From: Kyle M. <ky...@de...> - 2002-02-26 04:04:50
|
(i'll get used to this sooner or later... sourceforge appears to not
like setting the reply-to)
On Mon, Feb 25, 2002 at 10:46:23AM +0100, Herbert Valerio Riedel wrote:
> oh yes, that's the other thing I forgot...
> I want the distribution to be that modular, that one can build easily
> distros without strong ciphers, and since ciphers are self-registering
> witht the crypto-api, one can distribute the idea cipher as a
> self-contained package...
>
Very good, this makes it much easier to get around patent and export
laws, although, I should be okay, I'm a Canadian ;)
> well, encrypted root is possible with linux afaik;
> encrypted swap in theory as well over loop, although a more direct
> approach would be more elegant (there's some paper about encrypting VM
> at the openbsd site)
>
I've just looked at this, it looks feasible. The question, I guess, is
CryptoAPI going to get into implementing things, or leave that to the
kernel-patch-int. Actually, is kernel-patch-int even maintained or
developed these days? Or perhaps for 2.5 a full-fledged crypto kernel
patch with _everything_ integrated together.
Anyway, I pulled CVS down, and have been getting familiar with the
source. I should be ready to be productive in a couple more days.
regards,
kyle
> --
> 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
--
copyleft (c) 2002, Kyle McMartin
|
|
From: Kyle M. <ky...@de...> - 2002-02-26 02:50:24
|
On Mon, Feb 25, 2002 at 10:54:19AM +0100, Herbert Valerio Riedel wrote: > well... the cryptoapi in it's current form should be version > independent! :-) > Indeed, if this can be accomplished, it is indeed good. > actually there's no sense for the tarball distro to carry a kernel > version number... only for the kernel patch distro... > > the only annoying stuff that changes a bit is the top-level Makefile, > and some other minor bits in the build framework... > This will all stabilize... eventually, I guess it isn't really an issue with judicious shell scripting. > btw, so far the USAGI and a NFSv4 project is already using the > cryptoapi; > the frees/wan people are thinking about using it, but are a bit > disappointed about the current status... > FreeS/WAN also seems to be in the middle of a complete re-design, so compounding their troubles might not go over well :> regards, kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-25 20:49:42
|
On Mon, 2002-02-25 at 10:50, David Bryson wrote: > Ok, so a few questions so clear a few things up for me. Again, i'm a > newbie so go easy on me, but flames are appriciated it absolutly > necessary ;-) ...why should I flame? ;) =20 > My understanding of how the API works is: > block write request-> filesystem > write(ext2/3/reiserfs/whatever)->loopback(crypto)->block written. =20 > The whole loopback thing seems a little odd to me, why is it necessary > that we go through the loopback device ? Couldn't we interrupt the > system call for block writing and encrypt the contents there, maybe on > the VFS layer ?=20 if you do it in the vfs layer, you will only encrypt the data (file contents), but not the meta-data (i.e. filenames, dirstructure and so on) by using the loopback device, the filesystem does not need to be adapted anyway, as it just sees the usual block device abstraction on which to operate... > My current understanding of the whole CryptoAPI is that > the loopback device limits us in some sense, so I'm trying to figure out > if there is a way we can accomplish the same task without it. Is this > futile ? the loopback device is just an application of the cryptoapi, it's not its main purpose ;) =20 > Also... I know you guys are on the list but: >=20 > Cryptoapi people seem to be very reluctant to fixing bugs, even if said > bugs are pointed out to maintainer. well the only 'cryptoapi people' you can be referring to is me... ;) =20 > we should really try to change that. hvr do you have a list of bugs > that have been reported to you lying around in some old emails ? I'll put something together, although there were not many real bugs reported (most of the problems are failed kernel compiles or failing to load a module, or something similiar...) 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 |
|
From: David B. <db...@du...> - 2002-02-25 16:43:45
|
Ok, so a few questions so clear a few things up for me. Again, i'm a newbie so go easy on me, but flames are appriciated it absolutly necessary ;-) My understanding of how the API works is: block write request-> filesystem write(ext2/3/reiserfs/whatever)->loopback(crypto)->block written. The whole loopback thing seems a little odd to me, why is it necessary that we go through the loopback device ? Couldn't we interrupt the system call for block writing and encrypt the contents there, maybe on the VFS layer ? My current understanding of the whole CryptoAPI is that the loopback device limits us in some sense, so I'm trying to figure out if there is a way we can accomplish the same task without it. Is this futile ? Also... I know you guys are on the list but: Cryptoapi people seem to be very reluctant to fixing bugs, even if said bugs are pointed out to maintainer. we should really try to change that. hvr do you have a list of bugs that have been reported to you lying around in some old emails ? Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-25 09:54:30
|
On Mon, 2002-02-25 at 02:53, Kyle McMartin wrote: > (sorry forgot to send this to the mailing list) np :-) =20 > > 1. how to automate the task of creating a kernel patch from the > > cryptoapi-CVS? or maybe just do it like the frees/wan people do? > This one should be easy, do all development in a HEAD branch, and when a > new kernel is released, create a branch for it, and stabilize the > branch, while all main work continues on HEAD. well... the cryptoapi in it's current form should be version independent! :-) actually there's no sense for the tarball distro to carry a kernel version number... only for the kernel patch distro... the only annoying stuff that changes a bit is the top-level Makefile, and some other minor bits in the build framework... =20 > Only problem with this approach is releases for old kernels stagnates, > so sticking to the stable tree, where people are nearly guaranteed to > upgrade, is okay. as said above, these scheme would apply, if the cryptoapi would mess around with kernel internals which may change every version... but it's quite self-contained.. it just adds source files; it doesn't modify existing kernel source... =20 > I'll suck down the cvs tree in a few minutes. Seeing how long it is > taking for 2.4.18, I think shooting for a stable version for it would be > a good idea, since at this rate it will be current for ages. >=20 > I suppose coordination with the FreeS/WAN people would be a good idea, > especially if they began using the CryptoAPI ciphers. btw, so far the USAGI and a NFSv4 project is already using the cryptoapi; the frees/wan people are thinking about using it, but are a bit disappointed about the current status... =20 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 |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-25 09:46:34
|
On Sun, 2002-02-24 at 20:06, David Bryson wrote: > So kyle and I breifly spoke about the IDEA algorithm being in the API.=20 > Since it is still patented(until 2007 IIRC) we felt it shouldn't be in > there and should be available seperately as a patch. Thoughts on this ? > I haven't had a chance to pour over the sources for a few hours, and get > to know them, but I plan to soon. oh yes, that's the other thing I forgot... I want the distribution to be that modular, that one can build easily distros without strong ciphers, and since ciphers are self-registering witht the crypto-api, one can distribute the idea cipher as a self-contained package... and then again, there'd be the problem of how to create a patch out of the standalone distro... > I'm also looking into how cfs was > designed for OpenBSD because it would be nice if linux could eloquently > support encrypted root/swap. well, encrypted root is possible with linux afaik; encrypted swap in theory as well over loop, although a more direct approach would be more elegant (there's some paper about encrypting VM at the openbsd site) --=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 |
|
From: David B. <db...@du...> - 2002-02-25 01:59:41
|
So kyle and I breifly spoke about the IDEA algorithm being in the API.=20 Since it is still patented(until 2007 IIRC) we felt it shouldn't be in there and should be available seperately as a patch. Thoughts on this ? I haven't had a chance to pour over the sources for a few hours, and get to know them, but I plan to soon. I'm also looking into how cfs was designed for OpenBSD because it would be nice if linux could eloquently support encrypted root/swap. cheers, dave On Sun, 2002-02-24 at 17:02, Herbert Valerio Riedel wrote: > On Sun, 2002-02-24 at 19:22, Kyle McMartin wrote: > > one two three. > works! >=20 > well, I'll take the opportunity write about the current status; >=20 > ...we are quite alone here, just 3 of us in the mailing list so far... > hope we become more over time :) >=20 > ok, so we have=20 >=20 > 1. a 'cryptoapi-2.4.7' tarball which is a bit out of date at > sourceforge.net > 2. a CVS repository containing the latest cryptoapi code at sourceforge > 3. the old kernel patches up to 2.4.3 at kernel.org (by alex) > 4. the 'testing' patches up to 2.4.17 at kernel.org (by me), containing > code from the cryptoapi-branch... >=20 > some unresolved problem which kept me from releasing this beast finally > are: >=20 > 1. how to automate the task of creating a kernel patch from the > cryptoapi-CVS? or maybe just do it like the frees/wan people do? > 2. how to handle jari's and my loop-IV fix approach in a compatible way. > 3. documentation update > 4. some stuff I forgot... :-/ >=20 > ..if something is unclear (and I'm sure there is :-), please don't > hesitate to ask! :-) >=20 > 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 |
|
From: Kyle M. <ky...@de...> - 2002-02-25 01:53:50
|
(sorry forgot to send this to the mailing list) On Mon, Feb 25, 2002 at 01:02:11AM +0100, Herbert Valerio Riedel wrote: > 1. how to automate the task of creating a kernel patch from the > cryptoapi-CVS? or maybe just do it like the frees/wan people do? > 2. how to handle jari's and my loop-IV fix approach in a compatible way. > 3. documentation update > 4. some stuff I forgot... :-/ > This one should be easy, do all development in a HEAD branch, and when a new kernel is released, create a branch for it, and stabilize the branch, while all main work continues on HEAD. Only problem with this approach is releases for old kernels stagnates, so sticking to the stable tree, where people are nearly guaranteed to upgrade, is okay. I'll suck down the cvs tree in a few minutes. Seeing how long it is taking for 2.4.18, I think shooting for a stable version for it would be a good idea, since at this rate it will be current for ages. I suppose coordination with the FreeS/WAN people would be a good idea, especially if they began using the CryptoAPI ciphers. I'll being by looking into the documentation, that should be a good way of getting my feet wet. regards, kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-02-25 00:02:19
|
On Sun, 2002-02-24 at 19:22, Kyle McMartin wrote: > one two three. works! well, I'll take the opportunity write about the current status; ...we are quite alone here, just 3 of us in the mailing list so far... hope we become more over time :) ok, so we have=20 1. a 'cryptoapi-2.4.7' tarball which is a bit out of date at sourceforge.net 2. a CVS repository containing the latest cryptoapi code at sourceforge 3. the old kernel patches up to 2.4.3 at kernel.org (by alex) 4. the 'testing' patches up to 2.4.17 at kernel.org (by me), containing code from the cryptoapi-branch... some unresolved problem which kept me from releasing this beast finally are: 1. how to automate the task of creating a kernel patch from the cryptoapi-CVS? or maybe just do it like the frees/wan people do? 2. how to handle jari's and my loop-IV fix approach in a compatible way. 3. documentation update 4. some stuff I forgot... :-/ ..if something is unclear (and I'm sure there is :-), please don't hesitate to ask! :-) 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 |
|
From: Kyle M. <ky...@de...> - 2002-02-24 18:22:28
|
one two three. - k -- copyleft (c) 2002, Kyle McMartin |
