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: Justin C. <ju...@po...> - 2002-03-05 01:28:10
|
Hi guys, Just started adding the existing cryptoAPI patches to the "Files" section of the Sourceforge project. Not all of them are there yet, the rest should be added tonight though, as I have to go to work now. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Justin C. <ju...@po...> - 2002-03-05 00:51:35
|
Hi Herbert, Herbert Valerio Riedel wrote: > > On Mon, 2002-03-04 at 18:02, Justin Clift wrote: > > As well as the kernel patches, I feel it's worth putting the CryptoAPI's > > util-linux patches on the site, but am not sure whether both the 2.11i > > and 2.11n one's should be there, or just the 2.11n ones. From memory, > > I've been using the 2.11i ones and haven't really looked at the 2.11n > > ones. Would like people's opinions on this, etc. > > I'm not really opposed to it, but on the other hand maybe some link to > ftp.kernel.org for the patch-int's would be better, since there we can > get those patches gpg-signed w/ kernel.org signature.... while on > sourceforge it would require some more work to reliably verify the > integrity of the sources... I can see what you mean with that. Sounds like the web-page needs to have a few more links, as I don't think we can put links from the "Files" section on the sourceforge site. I don't understand why we can't have the the patches signed with the gpg kernel.org signature, wherever they are for download. Then again, I haven't used gpg which probably explains why. :) <snip> > 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 > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: PGP Armored File (application/x-unknown-content-type-PGP Armored File) > Description: This is a digitally signed message part -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Justin C. <ju...@po...> - 2002-03-05 00:39:41
|
Hi all, How about this as a start... The project decides which license it's going to "officially" support, and states up front that all patches to this code which people donate are going to be covered by that same license. This was if people don't want their patches under that licese, don't post the patches. But, which license? I think we should be careful here too. Chosing BSD means the GPL people will generally kick up a stink, and choosing GPL can mean the company-friendly people will kick up a stink, etc. Sometime the licensing argument can get so bad that people will actually leave projects, etc. :( My vote is to keep the code the same as the Linux kernel, as that's where we want it included anyway. :-) Regards and best wishes, Justin Clift Herbert Valerio Riedel wrote: > > On Mon, 2002-03-04 at 20:58, David Bryson wrote: > > eek these were both my suggestion to kyle, my bad. > np, it's cvs... everything can be reverted... :-) > > > > 3.) we can't claim something changed to be GPL'ed, if we don't have the > > > copyright to do so... this could bring us into major legal problems... > > is this in regards to "declaring" all of the module licenses GPL ? In > > which case should we be trying to hunt down all the original maintainers > > of the code and asking them if we can GPL it ? > > some are X11-style licenses (i.e. the api itself by alex et al. is > declared such iirc) > some are GPL'ed (the cryptoloop module I (re)wrote) or the twofish > implementation taken from the gpg project... > > some are BSDish... and some others are public domain.. > > btw, do we really need everything to be GPLed? i.e. the patented algos > might not be gpl'able... but I'm not sure right now... > > 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 > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: PGP Armored File (application/x-unknown-content-type-PGP Armored File) > Description: This is a digitally signed message part -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: David B. <db...@du...> - 2002-03-04 22:39:49
|
On Mon, 2002-03-04 at 14:21, Herbert Valerio Riedel wrote: > On Mon, 2002-03-04 at 20:58, David Bryson wrote: > > eek these were both my suggestion to kyle, my bad. > np, it's cvs... everything can be reverted... :-) >=20 > > > 3.) we can't claim something changed to be GPL'ed, if we don't have t= he > > > copyright to do so... this could bring us into major legal problems..= . > > is this in regards to "declaring" all of the module licenses GPL ? In > > which case should we be trying to hunt down all the original maintainer= s > > of the code and asking them if we can GPL it ? >=20 > some are X11-style licenses (i.e. the api itself by alex et al. is > declared such iirc) > some are GPL'ed (the cryptoloop module I (re)wrote) or the twofish > implementation taken from the gpg project... >=20 > some are BSDish... and some others are public domain.. Not that this is a bad thing, but I'm pretty sure the debian people for example(correct me if i'm wrong kyle) will only put in OSI certified licenses to their distro. GPL is just a nice to "not worry" about it from our programming perspective. >=20 > btw, do we really need everything to be GPLed? i.e. the patented algos > might not be gpl'able... but I'm not sure right now... >=20 I don't think they should *have* to be GPL'd but the api is GPL'd.. correct ? BTW if you and others do not know, we have a #crypto room on OPN where kyle and i converse rather often. Please come on by and chat with us about things, heh it's all we ever do ;-). Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 21:39:32
|
On Mon, 2002-03-04 at 21:45, Kyle McMartin wrote: > alright. i considered reverting all my changes with cvs, but i felt this > to be unnecessary. well, as long as you don't forget to revert the kbuild patch ;-) cause that's a bigger technical show-stopper... =20 > what i do need, however, is clarification on how cryptoapi is licensed. > from what i can see, it is a mishmash of differently licensed code, > which is bad, imho. please grab the last patch-int-2.4.3 which was created by alex, as this contains a readme.license or something like this... it may help... but you'll have to look closely at the comment header of each source file, and try to find out what kind of license it is... =20 > is it possible for you to tell me which directories are covered by what? > i'll assume the cryptoapi.c is GPL as per the original license, however > the new cryptoapi2 module does not contain any license at all. this > leads to abit of confusion. well it's just because I wanted to postpone the license question.... but well, we can handle it now as well... it's just a nasty issue which needs to be done sooner or later... :-/ =20 > i'll back out the MODULE_LICENSE changes on ciphers and digests in the > meantime and fix the kbuild, since these seem to be priority. ... but you felt it to be unnecessary... ;) 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-04 21:35:19
|
On Mon, 2002-03-04 at 22:25, Kyle McMartin wrote: > > well, in order to do so, we should convince them in the first place, > > that cryptoapi's cryptoloop and the crypotapi itself is a mature piece > > of code... > i guess making the ciphers endian independant is the first issue... I fixed 4 lately, rc5, rc6, blowfish and another aes finalist I don't remember....=20 I remember issues with idea, dfc and maybe one else (see my last mail regarding this issue)... =20 > > the unclear state of maintenance has earned this project a bad > > reputation; and jari's negative press (which only in part was true) > > hasn't helped much either...=20 > i have a question about this, does cryptoapi replace kernel-int or does > kernel-int still exist? cryptoapi is just a name for the tarball packaging I chosed, since nonpatch-int sounded too stupid for a non-patch distribution ;) =20 also cryptoapi seemed a good buzzword... :-) i.e. patch-int and cryptoapi are supposed to mean the same... should we get cryptoapi-0.1.0.tar.gz (or whatever version it may become) ready the patch-int's will have to carry names as patch-int-2.4.18-0.1.0.gz ...in order to better reflect the versioning scheme... 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-04 21:24:59
|
On Mon, Mar 04, 2002 at 10:15:00PM +0100, Herbert Valerio Riedel wrote: > well, in order to do so, we should convince them in the first place, > that cryptoapi's cryptoloop and the crypotapi itself is a mature piece > of code... > i guess making the ciphers endian independant is the first issue... > the unclear state of maintenance has earned this project a bad > reputation; and jari's negative press (which only in part was true) > hasn't helped much either... > i have a question about this, does cryptoapi replace kernel-int or does kernel-int still exist? > on the other hand, we have the benefit of being the more or less > official crypto extension for the linux kernel... should we lose this as > well, we can give up completely... :-/ > nod, i guess we'll have to make sure it doesn't :) - k -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 21:21:52
|
On Mon, 2002-03-04 at 20:58, David Bryson wrote: > eek these were both my suggestion to kyle, my bad. np, it's cvs... everything can be reverted... :-) > > 3.) we can't claim something changed to be GPL'ed, if we don't have the > > copyright to do so... this could bring us into major legal problems... > is this in regards to "declaring" all of the module licenses GPL ? In > which case should we be trying to hunt down all the original maintainers > of the code and asking them if we can GPL it ? some are X11-style licenses (i.e. the api itself by alex et al. is declared such iirc) some are GPL'ed (the cryptoloop module I (re)wrote) or the twofish implementation taken from the gpg project... some are BSDish... and some others are public domain.. btw, do we really need everything to be GPLed? i.e. the patented algos might not be gpl'able... but I'm not sure right now... 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-04 21:15:12
|
On Mon, 2002-03-04 at 21:16, Kyle McMartin wrote: > On Mon, Mar 04, 2002 at 06:34:05PM +0100, Herbert Valerio Riedel wrote: > > btw, some ready to use util-linux crypto-enhanced rpm packages would > > surely boost the user base... as most distros use rpm's today... > i feel it would also be worth mentioning that debian ships these > packages by default. perhaps other distribution vendors could be > convinced to do the same. (well, those that are based in the free world, > where hooks to crypto doesn't necessarily mean implements crypto) well, in order to do so, we should convince them in the first place, that cryptoapi's cryptoloop and the crypotapi itself is a mature piece of code... the unclear state of maintenance has earned this project a bad reputation; and jari's negative press (which only in part was true) hasn't helped much either...=20 on the other hand, we have the benefit of being the more or less official crypto extension for the linux kernel... should we lose this as well, we can give up completely... :-/ 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-04 21:04:39
|
..any volunteer to investigate a bit? if util-linux asks twice for password it's usually a sign of some module not loaded... but well.. -- 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-04 20:45:46
|
hvr, alright. i considered reverting all my changes with cvs, but i felt this to be unnecessary. what i do need, however, is clarification on how cryptoapi is licensed. from what i can see, it is a mishmash of differently licensed code, which is bad, imho. is it possible for you to tell me which directories are covered by what? i'll assume the cryptoapi.c is GPL as per the original license, however the new cryptoapi2 module does not contain any license at all. this leads to abit of confusion. i'll back out the MODULE_LICENSE changes on ciphers and digests in the meantime and fix the kbuild, since these seem to be priority. sorry about the mix up, kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Kyle M. <ky...@de...> - 2002-03-04 20:17:48
|
fwd of private message to hvr. On Mon, Mar 04, 2002 at 03:14:44PM -0500, Kyle McMartin wrote: > On Mon, Mar 04, 2002 at 01:42:57PM +0100, Herbert Valerio Riedel wrote: > > 1.) the kbuild patch should neither add a kernel suffix (I was tented > > myself long time ago; but this 1. would require to have such a patch for > > _every_ kernel version out there... and 2ndly it will break peoples > > custom kernels... so don't do it :-) > > 2.) the kbuild patch, as the name already says, should touch _only_ > > makefiles and other build-related control files... so the loop.c patch > > doesn't belong in there for at least one reason; the other reason is, > > that people may prefer the loop-jari patch, and this would conflcit; so > > don't do this either.. > > > sorry, i should have mentioned in the changelog that these were just > temporary until i could put together some other framework for adding > miscellenous crypto patches to the api. i'll revert it until i can do > that. > > > 3.) we can't claim something changed to be GPL'ed, if we don't have the > > copyright to do so... this could bring us into major legal problems... > > > oh shhhhblah. i assumed all the code was taken from the public domain. i > will fix this right away. would it be alright if i added a Makefile > target to build only ciphers which can be gpl-licensed? > > -- > copyleft (c) 2002, Kyle McMartin -- copyleft (c) 2002, Kyle McMartin |
|
From: Kyle M. <ky...@de...> - 2002-03-04 20:16:51
|
On Mon, Mar 04, 2002 at 06:34:05PM +0100, Herbert Valerio Riedel wrote: > btw, some ready to use util-linux crypto-enhanced rpm packages would > surely boost the user base... as most distros use rpm's today... > i feel it would also be worth mentioning that debian ships these packages by default. perhaps other distribution vendors could be convinced to do the same. (well, those that are based in the free world, where hooks to crypto doesn't necessarily mean implements crypto) -- copyleft (c) 2002, Kyle McMartin |
|
From: David B. <db...@du...> - 2002-03-04 20:01:50
|
On Mon, 2002-03-04 at 05:42, Herbert Valerio Riedel wrote: > On Sun, 2002-03-03 at 22:31, Kyle McMartin wrote: > > checked in a nice version of my code. everything seems to work well. > > screwed up the changelog entry, unfortunatly, and forgot to include a > > linebreak in it so it runs on... ah well. > >=20 > > cvs update, i guess. > >=20 > > everything seems to work well though, and sf has my ssh2 key. excellent= . > >=20 > > enjoy the rest of your weekend :) >=20 > looks good :-), except for 2 major things... >=20 eek these were both my suggestion to kyle, my bad. > please revert the kbuild patch; this isn't the right thing... > 1.) the kbuild patch should neither add a kernel suffix (I was tented > myself long time ago; but this 1. would require to have such a patch for > _every_ kernel version out there... and 2ndly it will break peoples > custom kernels... so don't do it :-) > 2.) the kbuild patch, as the name already says, should touch _only_ > makefiles and other build-related control files... so the loop.c patch > doesn't belong in there for at least one reason; the other reason is, > that people may prefer the loop-jari patch, and this would conflcit; so > don't do this either.. > 3.) we can't claim something changed to be GPL'ed, if we don't have the > copyright to do so... this could bring us into major legal problems... is this in regards to "declaring" all of the module licenses GPL ? In which case should we be trying to hunt down all the original maintainers of the code and asking them if we can GPL it ? Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 17:34:17
|
On Mon, 2002-03-04 at 18:02, Justin Clift wrote: > As well as the kernel patches, I feel it's worth putting the CryptoAPI's > util-linux patches on the site, but am not sure whether both the 2.11i > and 2.11n one's should be there, or just the 2.11n ones. From memory, > I've been using the 2.11i ones and haven't really looked at the 2.11n > ones. Would like people's opinions on this, etc. I'm not really opposed to it, but on the other hand maybe some link to ftp.kernel.org for the patch-int's would be better, since there we can get those patches gpg-signed w/ kernel.org signature.... while on sourceforge it would require some more work to reliably verify the integrity of the sources... btw, keep in mind, that the new planned distribution style will try to become version indepent, i.e. you download a tar-ball and it does the required patching of your kernel automatically; thus we should be able to provide many kernel versions with the latest API... this will be a major breakthrough in versioning wrt to the international kernel patch... =20 > It should make for a good next step, and we can see if this helps expand > the userbase of people using crypto stuff with Linux (appropriately), > and also find out if this makes it easier for the people already using > cryptoAPI to keep up to date. btw, some ready to use util-linux crypto-enhanced rpm packages would surely boost the user base... as most distros use rpm's today... next night might be ready to use kernel rpms (at least for the most common distros), that might be another killer application... I'd have a strange feeling, if I were to trust binaries I didn't compile myself... but well, not all users are at this level of paranoia... :-) 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: Justin C. <ju...@po...> - 2002-03-04 17:04:43
|
Hi everyone, I've volunteered to help out the CryptoAPI project by taking the time to put the CryptoAPI patches in the SourceForge sites' "Files" section so people can download them directly from there, and might be able to help here and there with other CryptoAPI-SF.net things. As well as the kernel patches, I feel it's worth putting the CryptoAPI's util-linux patches on the site, but am not sure whether both the 2.11i and 2.11n one's should be there, or just the 2.11n ones. From memory, I've been using the 2.11i ones and haven't really looked at the 2.11n ones. Would like people's opinions on this, etc. It should make for a good next step, and we can see if this helps expand the userbase of people using crypto stuff with Linux (appropriately), and also find out if this makes it easier for the people already using cryptoAPI to keep up to date. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-04 12:43:09
|
On Sun, 2002-03-03 at 22:31, Kyle McMartin wrote: > checked in a nice version of my code. everything seems to work well. > screwed up the changelog entry, unfortunatly, and forgot to include a > linebreak in it so it runs on... ah well. >=20 > cvs update, i guess. >=20 > everything seems to work well though, and sf has my ssh2 key. excellent. >=20 > enjoy the rest of your weekend :) looks good :-), except for 2 major things... please revert the kbuild patch; this isn't the right thing... 1.) the kbuild patch should neither add a kernel suffix (I was tented myself long time ago; but this 1. would require to have such a patch for _every_ kernel version out there... and 2ndly it will break peoples custom kernels... so don't do it :-) 2.) the kbuild patch, as the name already says, should touch _only_ makefiles and other build-related control files... so the loop.c patch doesn't belong in there for at least one reason; the other reason is, that people may prefer the loop-jari patch, and this would conflcit; so don't do this either.. 3.) we can't claim something changed to be GPL'ed, if we don't have the copyright to do so... this could bring us into major legal problems... 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-03 21:31:41
|
checked in a nice version of my code. everything seems to work well. screwed up the changelog entry, unfortunatly, and forgot to include a linebreak in it so it runs on... ah well. cvs update, i guess. everything seems to work well though, and sf has my ssh2 key. excellent. enjoy the rest of your weekend :) kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Kyle M. <ky...@de...> - 2002-03-02 22:34:09
|
alright. here we go, i think i've grasped cvs better. i do propose however, that we rename kbuild-VER to cryptoapi-VER.diff or something, since having a file named kbuild-VER in their top level kernel directory might confuse some people. also, what is your opinion on bitkeeper? summary of changes: + synced to the latest cvs pull at ~1300 EST. + reorganized Config.in's (where exactly does cryptoloop get set, i cannot find it) + rc5 patch from you. + MODULE_* set for all modules. + new top level Makefile. + cleaned up some comments and some trailing whitespace at the end of some files. - k -- copyleft (c) 2002, Kyle McMartin |
|
From: Kyle M. <ky...@de...> - 2002-03-02 21:46:33
|
I'd prefer it if you didn't apply this, I'll have a much better cvs-style patch out by the end of the day which I will send. regards, kyle On Sat, Mar 02, 2002 at 08:52:47PM +0100, Herbert Valerio Riedel wrote: > On Sat, 2002-03-02 at 20:37, Kyle McMartin wrote: > > alright, this should be clean. i figured since i moved some stuff around > > the easiest solution would be to just tar this up and put it online. > > > > looked good to me. all it needs is a way to determine kernel versioning > > in the top level Makefile. > > thx, I'll take a look at it asap > > btw, please run a 'cvs update' regularly... and it's better to send a > cvs diff... :-) > > -- > 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-03-02 19:51:38
|
Erp. I meant to send a diff, *sigh*. In a couple minutes I will post a diff, and remember to not include the crypto/ subdir of include/linux. -k -- copyleft (c) 2002, Kyle McMartin |
|
From: Kyle M. <ky...@de...> - 2002-03-02 19:38:06
|
alright, this should be clean. i figured since i moved some stuff around the easiest solution would be to just tar this up and put it online. looked good to me. all it needs is a way to determine kernel versioning in the top level Makefile. -- copyleft (c) 2002, Kyle McMartin |
|
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
|
|
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 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 |
