Menu
▾
▴
cryptoapi-devel
|
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: 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: 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 10:08:32
|
On Sat, 2002-03-02 at 04:01, Kyle McMartin wrote: > > ...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. sorry, can't find it, could forward it to me plz? :-) > 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. try 'make version', that's a new target I added yesterday - it creates a file 'version'...=20 this approach has the drawback, that the kernel has to be configured already, so it's not the ideal way... one could also try to extract the kernel version out of the Makefile by doing some clever regexp matching with sed... e.g. something like=20 grep '^VERSION' /usr/src/linux/Makefile | sed 's/VERSION *=3D *\([0-9][0-9]= *\)/\1/g' ps: I've just verified, that some ciphers are broken on big endian (mars, rc6, idea, rc5) and another, dfc, seems to be broken completely... :-( so we have quite a TODO list... for mars and rc6 we have test vectors (see the cryptoapi-test module), but not for the rest... :-/ I'll start to fix mars and rc6, as I've got test vectors to verify against... 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 12:11:24
|
On Sat, 2002-03-02 at 11:08, Herbert Valerio Riedel wrote: > ps: I've just verified, that some ciphers are broken on big endian > (mars, rc6, idea, rc5) ok, we can take mars and rc6 from the list of broken ciphers, as I've fixed them finally... btw, rotr() behaved quite differently on ppc...=20 i.e. one has to make sure, the shift argument is passed modulo % 32 ... =20 > and another, dfc, seems to be broken completely... :-( well, I've spent enough time for today, chasing assembler output...=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-03-02 13:18:40
|
On Sat, 2002-03-02 at 01:58, Kyle McMartin wrote:
> - 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.
finally I found the bug report...! :-)
btw, what's wrong with the patch below, which was attached to the bug
report...
#define w 32 /* word size, in bits */
#define r 16 /* rounds */
#define b 16 /* minimum key size in bytes */
-#define c 8 /* same for 128, 192 and 256 bits key */
+#define max_c 8 /* same for 128, 192 and 256 bits key */
#define t 34 /* size of table S, t =3D 2 * (r + 1) */
=20
/* RC5 encryption */
@@ -81,11 +81,12 @@
{
u4byte *in_key =3D (u32 *)key;
u4byte *out_key =3D cx->keyinfo; /* S */
- u32 i, j, k, A, B, L[c];
+ u32 i, j, k, A, B, L[max_c], c;
=20
if (key_len < b || key_len > (2 * b))
return -1;
=20
+ c =3D key_len / (w/8);
key_len *=3D 8;
=20
/* init L */
--=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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X