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: David B. <db...@du...> - 2002-04-09 17:07:04
|
Ok so, here are the important things before we release, this is my compiled list of things hvr and i have chatted about. Some of which I am hoping to accomplish: 1) rc5 fix 2) Documentation, finish the README's and such. I'm not quite sure what all needs to be in here, so i'll ask some people what kind of stuff they need in there. 3) "find closest patch", a perl script that finds the kernel version closest to what version your patching(for loop-iv script) 4) rewrite DES/3DES, I mean seriously... it's nasty to look at Kyle, i know your busy this week, but i was wondering if you had a document that described our proposed coding standards. If you do, send it out to the list. everyone else, are there other issues of importance before we release ? Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-08 15:09:00
|
On Mon, 2002-04-08 at 13:43, Kyle McMartin wrote: >> aes, dfc, mars, rc5, rc6: looks like 4-clause BSD >> (most are written by gladman... maybe we can get him to change the >> license to "dual GPL/BSD"? that way we would have most of the work >> done...) > I recall him stating that he had no objection to his ciphers being used i= n Free software works, but we'd better email him to check. His license is m= ore or less, use it how you wish, subject to the restrictions placed upon t= he algorithm by its creators. I would interpret this as public domain, if t= he algorithm itself is public domain. well, I've seen such a passage myself... you can find it in jari's aes.c file right at the beginning: // I retain copyright in this code but I encourage its free use provided // that I don't carry any responsibility for the results. I amespecially //= happy to see it used in free and open source software. If you do use=20 // it I would appreciate an acknowledgement of its origin in the code or // the product that results and I would also appreciate knowing a little // about the use to which it is being put. I am grateful to Frank Yellin // for some ideas that are used in this implementation. // // Dr B. R. Gladman <br...@gl...> 6th April 2001. see also http://lists.freeswan.org/pipermail/design/2001-December/001595.html jari declares his aes implementation (which is derived from gladmans 4-clause AES implementation as well... but a more recent version...) to be GPL'ed -- he does this implicitly, by defining MODULE_LICENSE("GPL") in loop.c, which links against aes.c and results in a loop.o module... well... I really don't know, if his doing so is the right thing or not... IMHO we should get some official statement from gladman himself, to find out whether he is ok w/ dual licensing his work... and/or what he thinks about the license of our currently used aes implementation, which is definitely a bit older... btw, official URL for gladman's aes implementation: http://fp.gladman.plus.com/cryptography_technology/rijndael/index.htm >> idea: no license?!? > I don't think it matters, since its patented. The question is can we be h= eld accountable for breaches of the algorithms patent? (no commercial use).= .. well... I'm toying w/ the idea to move cipher-idea to the yet to be created add-on cipher package... 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-04-08 11:42:28
|
On Mon, Apr 08, 2002 at 11:49:09AM +0200, Herbert Valerio Riedel wrote:
>=20
> I remember someone wanted to try and reach the copyright holders of the
> ciphers which are not yet GPL compatible....
>=20
*nod*
> aes, dfc, mars, rc5, rc6: looks like 4-clause BSD
> (most are written by gladman... maybe we can get him to change the
> license to "dual GPL/BSD"? that way we would have most of the work
> done...)
>=20
I recall him stating that he had no objection to his ciphers being used in =
Free software works, but we'd better email him to check. His license is mor=
e or less, use it how you wish, subject to the restrictions placed upon the=
algorithm by its creators. I would interpret this as public domain, if the=
algorithm itself is public domain.
> idea: no license?!?
>
I don't think it matters, since its patented. The question is can we be hel=
d accountable for breaches of the algorithms patent? (no commercial use)...
=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
regards,
Kyle M.
--=20
copyleft (c) 2002, Kyle McMartin
|
|
From: Herbert V. R. <hv...@hv...> - 2002-04-08 09:49:17
|
I remember someone wanted to try and reach the copyright holders of the ciphers which are not yet GPL compatible.... aes, dfc, mars, rc5, rc6: looks like 4-clause BSD (most are written by gladman... maybe we can get him to change the license to "dual GPL/BSD"? that way we would have most of the work done...) idea: no license?!? =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-04-03 14:21:39
|
On Tue, 2002-04-02 at 23:57, Gisle S{lensminde wrote:
> Here is a patch to make idea work again - that is - I swaped the code
> for big endian and little endian handling, and that seemed to be
> sufficient to get IDEA to work. With this patch it reproduces the
> test vectors. There is no handling of endianness in the key schedule, so
> it will probably not work on big endian systems.
thx!...
=20
> The thing I wrote about the IDEA key schedule was wrong. I was confused
> by pointer aritmetrics on the input parameter. Bad coding style, but the
> code worked.
...based on your fix I've cleaned up the idea cipher, and made it
endian-safe... and got rid of those #ifdef's.... should have become even
more readable now... (maybe it lost a bit of performance, but at the
moment correctness is more important to me than speed... ;-)
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-04-02 23:50:49
|
PS: could you please supply the test vectors? ;-) we do not appear to
have any committed.
On Tue, Apr 02, 2002 at 11:57:57PM +0200, Gisle S{lensminde wrote:
>=20
> Here is a patch to make idea work again - that is - I swaped the code
> for big endian and little endian handling, and that seemed to be
> sufficient to get IDEA to work. With this patch it reproduces the
> test vectors. There is no handling of endianness in the key schedule, so
> it will probably not work on big endian systems.
>=20
--=20
copyleft (c) 2002, Kyle McMartin
|
|
From: Kyle M. <ky...@de...> - 2002-04-02 23:02:57
|
committed.
only rc5 left now :)
- k
On Tue, Apr 02, 2002 at 11:57:57PM +0200, Gisle S{lensminde wrote:
>=20
> Here is a patch to make idea work again - that is - I swaped the code
> for big endian and little endian handling, and that seemed to be
> sufficient to get IDEA to work. With this patch it reproduces the
> test vectors. There is no handling of endianness in the key schedule, so
> it will probably not work on big endian systems.
>=20
> The thing I wrote about the IDEA key schedule was wrong. I was confused
> by pointer aritmetrics on the input parameter. Bad coding style, but the
> code worked.
>=20
> (I have forgotten the password of my sourceforge account)
>=20
> --- cipher-idea.c Tue Apr 2 23:29:54 2002
> +++ cipher-idea.new.c Tue Apr 2 23:28:44 2002
> @@ -202,9 +202,9 @@
> x2 =3D *in++;
> x3 =3D *in++;
> x4 =3D *in;
> -#if defined(__LITTLE_ENDIAN)
> +#if defined(__BIG_ENDIAN)
> /* noop */
> -#elif defined(__BIG_ENDIAN)
> +#elif defined(__LITTLE_ENDIAN)
> x1 =3D (x1 >> 8) | (x1 << 8);
> x2 =3D (x2 >> 8) | (x2 << 8);
> x3 =3D (x3 >> 8) | (x3 << 8);
> @@ -239,12 +239,12 @@
> MUL(x4, *key);
>=20
> out =3D (u16 *) outbuf;
> -#if defined(__LITTLE_ENDIAN)
> +#if defined(__BIG_ENDIAN)
> *out++ =3D x1;
> *out++ =3D x3;
> *out++ =3D x2;
> *out =3D x4;
> -#elif defined(__BIG_ENDIAN)
> +#elif defined(__LITTLE_ENDIAN)
> x1 =3D low16(x1);
> x2 =3D low16(x2);
> x3 =3D low16(x3);
>=20
>=20
> --=20
> --
> Gisle S=E6lensminde ( gi...@ii... )
>=20
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going
> to land, and it could be dangerous sitting under them as they fly
> overhead. (from RFC 1925)
>=20
>=20
>=20
> _______________________________________________
> CryptoAPI-devel mailing list
> Cry...@li...
> https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel
--=20
copyleft (c) 2002, Kyle McMartin
|
|
From: Gisle S{l. <gi...@ii...> - 2002-04-02 21:58:12
|
Here is a patch to make idea work again - that is - I swaped the code
for big endian and little endian handling, and that seemed to be
sufficient to get IDEA to work. With this patch it reproduces the
test vectors. There is no handling of endianness in the key schedule, so
it will probably not work on big endian systems.
The thing I wrote about the IDEA key schedule was wrong. I was confused
by pointer aritmetrics on the input parameter. Bad coding style, but the
code worked.
(I have forgotten the password of my sourceforge account)
--- cipher-idea.c Tue Apr 2 23:29:54 2002
+++ cipher-idea.new.c Tue Apr 2 23:28:44 2002
@@ -202,9 +202,9 @@
x2 =3D *in++;
x3 =3D *in++;
x4 =3D *in;
-#if defined(__LITTLE_ENDIAN)
+#if defined(__BIG_ENDIAN)
/* noop */
-#elif defined(__BIG_ENDIAN)
+#elif defined(__LITTLE_ENDIAN)
x1 =3D (x1 >> 8) | (x1 << 8);
x2 =3D (x2 >> 8) | (x2 << 8);
x3 =3D (x3 >> 8) | (x3 << 8);
@@ -239,12 +239,12 @@
MUL(x4, *key);
out =3D (u16 *) outbuf;
-#if defined(__LITTLE_ENDIAN)
+#if defined(__BIG_ENDIAN)
*out++ =3D x1;
*out++ =3D x3;
*out++ =3D x2;
*out =3D x4;
-#elif defined(__BIG_ENDIAN)
+#elif defined(__LITTLE_ENDIAN)
x1 =3D low16(x1);
x2 =3D low16(x2);
x3 =3D low16(x3);
--=20
--
Gisle S=E6lensminde ( gi...@ii... )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
|
|
From: Gisle S{l. <gi...@ii...> - 2002-04-01 23:05:14
|
On Mon, 1 Apr 2002, David Bryson wrote: > Suggestions below... > > On Fri, 29 Mar 2002, Kyle McMartin wrote: > > > The rest of it looks great. Although we should inclue in the makefile a > "make GPL" or something similar, and a "make nonfree". Some algortitms are patented and even the author has relesed the code as GPL, this will make the license invalid in som countries, and these algorithms should not be buildt by default. > Dave > > > _______________________________________________ > CryptoAPI-devel mailing list > Cry...@li... > https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel > --=20 -- Gisle S=E6lensminde ( gi...@ii... ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) |
|
From: David B. <db...@du...> - 2002-04-01 17:10:21
|
Suggestions below... On Fri, 29 Mar 2002, Kyle McMartin wrote: > I'm going to, after consensus, begin modifying the code to conform to > the standards that are the result of this thread. > > Most of this is secondary and can wait until after a release... > > To begin with, all code should follow the Linux kernels > Documentation/CodingStyle, with 8 space hard tabs (I need to convert the > code I've already written which uses soft tabs) and K&R style bracing. > > However, the real problem is the lack of unification in the design of > the ciphers. A quick look into the ciphers/ direction reveals everything > is implemented with different variable names, etc. The code should be > modified to be uniform throughout. > I think we should also unify our design for how the symmetric ciphers should be implemented. Great evidence of this being a Good Thing(tm) would be the difference between blowfish and des. The actual encryption code looks great, it's easy to read and understand: ROUND(leftword,rightword,roundnumber) If we could try to stick as close as possible to this design it would improve the readability of the ciphers and give us some kind of common thread among them, in addition to the changes proposed by kyle. > I propose, therefore, that all cipher dependant code, be prefixed with > the name of the cipher, ie: a context for the cipher like bf_ctx, would > be Blowfish_CTX. Perhaps all cipher dependant defines, like KEYLEN, > BLOCKSIZE, etc. could be prefixed with the cipher name as well. > > Now the more pressing matter, there are a number of patented and > GPL licensed modules in cryptoapi. If we wish to release and have people > integrate our code into their kernels (distributions, for example) we > must have the entire main cryptoapi package under the GPL or > dual-licensed. For example, Mandrake currently uses loop-AES, but would > be unable to include cryptoapi in their kernel, since we have patented and > non-free ciphers right there. > > To remedy this, I propose a directory hierarchy extension to the > ciphers/ directory. For example, all free, mainline ciphers could stay > in their current place, and we could have cryptoapi-patented and > cryptoapi-nonfree extension tarballs which fill up ciphers/patented/ and > ciphers/non-free/ The rest of it looks great. Although we should inclue in the makefile a "make GPL" or something similar, and a "make nonfree". Dave |
|
From: Justin C. <ju...@po...> - 2002-03-30 05:19:33
|
Hi Kyle, Kyle McMartin wrote: > > I'm going to, after consensus, begin modifying the code to conform to > the standards that are the result of this thread. > <snip> Not fussed about this one way or another. It will make it easier for future people to understand the code, which is probably a good idea. > Now the more pressing matter, there are a number of patented and > GPL licensed modules in cryptoapi. If we wish to release and have people > integrate our code into their kernels (distributions, for example) we > must have the entire main cryptoapi package under the GPL or > dual-licensed. For example, Mandrake currently uses loop-AES, but would > be unable to include cryptoapi in their kernel, since we have patented and > non-free ciphers right there. > > To remedy this, I propose a directory hierarchy extension to the > ciphers/ directory. For example, all free, mainline ciphers could stay > in their current place, and we could have cryptoapi-patented and > cryptoapi-nonfree extension tarballs which fill up ciphers/patented/ and > ciphers/non-free/ This seems to be a very decent first step to solve this problem. Almost making the non-GPL ciphers plug-in modules. In the future we might have a crypto-API which is pure GPL, and people can further install their chosen cipher if it's not in the GPL'd list. This would simplify some issues. :-) Regards and best wishes, Justin Clift > Comments, questions, flames? > > - k > > -- > copyleft (c) 2002, Kyle McMartin > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature -- "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: Kyle M. <ky...@de...> - 2002-03-29 23:23:10
|
I'm going to, after consensus, begin modifying the code to conform to the standards that are the result of this thread. Most of this is secondary and can wait until after a release... To begin with, all code should follow the Linux kernels Documentation/CodingStyle, with 8 space hard tabs (I need to convert the code I've already written which uses soft tabs) and K&R style bracing. However, the real problem is the lack of unification in the design of the ciphers. A quick look into the ciphers/ direction reveals everything is implemented with different variable names, etc. The code should be modified to be uniform throughout. I propose, therefore, that all cipher dependant code, be prefixed with the name of the cipher, ie: a context for the cipher like bf_ctx, would be Blowfish_CTX. Perhaps all cipher dependant defines, like KEYLEN, BLOCKSIZE, etc. could be prefixed with the cipher name as well. Now the more pressing matter, there are a number of patented and GPL licensed modules in cryptoapi. If we wish to release and have people integrate our code into their kernels (distributions, for example) we must have the entire main cryptoapi package under the GPL or dual-licensed. For example, Mandrake currently uses loop-AES, but would be unable to include cryptoapi in their kernel, since we have patented and non-free ciphers right there. To remedy this, I propose a directory hierarchy extension to the ciphers/ directory. For example, all free, mainline ciphers could stay in their current place, and we could have cryptoapi-patented and cryptoapi-nonfree extension tarballs which fill up ciphers/patented/ and ciphers/non-free/ Comments, questions, flames? - k --=20 copyleft (c) 2002, Kyle McMartin |
|
From: Gisle S{l. <gi...@ii...> - 2002-03-28 13:04:04
|
As I told, IDEA is broken. Both the cipher and the key schedule seems to be broken. In particular the key schedule is broken. If I have not done a mistake, the cipher is effectivly reduced to a two round cipher, since all but the first 12 subkeys seems to be always zero. This will make the cipher trivial to break if it's right. Using the test tools, with added debug printouts printing out subkeys, this is my result: [gisle@fisk tests]$ ./test_cipher -c idea-ecb -k \ ffffffffffffffffffffffffffffffff -p 0000000100020003 -e 5ae0bcea9fd5ae2d ffff - ffff - ffff - ffff - ffff - ffff - ffff - ffff - ffff - ffff - ffff - ffff - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 - 0000 =2E... Since idea merly distribute the keybits on the roundkeys, all roundkeys should have been 'ffff', but most of them will always be '0000' regardless of key. RC5 in kerneli seems to be RC5-32/16/16, and I don't have test vectors for that one. If anyone have, it would be nice. (That is rc5 with 32-bit wordsize, 16 rounds and 16 bytes of key material) -- Gisle S=E6lensminde ( gi...@ii... ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) |
|
From: David B. <db...@du...> - 2002-03-27 20:52:42
|
I commited cipher feedback mode today. It allows a block cipher to turn into a stream cipher, useful for network encryption. I also modified test_cipher in the cryptoapi-test module so that it would be easy for me to test different block modes. I added the -t flag, which lets you not enter cipher text to the test parameters. It then takes the key, plaintext and does E(k,p)->c->D(k,c)->p. Then checks to see if the plaintext at the end is the same as what it was given. I also updated the docs on it, so that it prints *slighty* more helpful -h option ;-) with descriptions of what the optons do. Dave |
|
From: David B. <db...@du...> - 2002-03-27 01:08:23
|
Ok i updated the docs that i commited earlier this week. The config options now conform to the 70 character line limit. I also made CAST5 work.. accidentally left out the variable last time(oops). Plus various other updates for cipher licenses and links. I'm going to hack losetup to deal with block mode appendings instead of just assuming cbc, so we'll be able to do: losetup -e CIPHER-cbc|ecb plus the other cipher modes i'm planning on implementing. hvr, i promise i won't mess with it till i read up on branching ;-). Dave |
|
From: Justin C. <ju...@po...> - 2002-03-25 14:54:52
|
Hi everyone, The util-linux RPM's have been added to the SF.net (Sourceforge) "File" list, so people can download them directly from the SF.net site. http://sourceforge.net/projects/cryptoapi/ http://sourceforge.net/project/showfiles.php?group_id=30957 :-) 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-25 08:12:35
|
On Mon, 2002-03-25 at 02:20, Ben Slusky wrote: > Looking at the SRPM, it seems that you've added SHA1 password hashing > into the old util-linux-cryptoapi patch. Now it occurs to me: maybe > instead of tacking hash algorithms onto util-linux, we might be better > off sending the unhashed password into kernelspace, and let cryptoloop > do the hashing itself. =20 > I can think of arguments for and against this. OOH, it seems like a > bad idea to make the kernel do what can be (and is) done just fine in > userspace. OTOH, we already have the digest algorithms in the kernel; > it seems like a waste to recode them, especially in a _separate_ patch, > and especially when the result is immediately handed off to cryptoloop. well... an argument against would be; say you had a monolithic kernel; then you'd have to carry around a digest implementation in kernel memory, just because you needed it once when setting up your loop device... on the other hand, it's already a nasty issue w/ managing cipher modules (i.e. some modules need to be loaded, before losetup can successfully set up a loop... otherwise you'll get some weird message...) if we add this digest dependancy as well, I expect more support requests from confused users to come... ...oh and btw, I don't plan to add more hashes to util-linux :-) 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-25 06:10:16
|
Kyle McMartin wrote: > <snip> > I also propose that we begin looking at adding assembler optimization to > as many of the ciphers, for as many platforms as possible. I'm not quite > sure what the best way to implement this would be though, as it has been > mentioned that Linus does not like bloating include/asm-platform > directories any more than already. <snip> Does someone want to ask him? It's pretty relevant. :-) Regards and best wishes, Justin Clift > - k > -- > copyleft (c) 2002, Kyle McMartin > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature -- "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: Kyle M. <ky...@de...> - 2002-03-25 05:25:44
|
After having looked through alot of the cipher code again tonight, I feel it would be a good idea to rework ^ rewrite the ciphers to follow a proper framework. Keep in mind I mean the ciphers themselves, not CryptoAPI. For example: all the different cipher contexts have different names internal to them, and I propose we transition them to a consistent naming scheme. After doing this, I believe we will have better control over the cipher implementations, and a standard set for ciphers which others may contribute to the project. I also propose that we begin looking at adding assembler optimization to as many of the ciphers, for as many platforms as possible. I'm not quite sure what the best way to implement this would be though, as it has been mentioned that Linus does not like bloating include/asm-platform directories any more than already. Since this is all under the hood, it can wait until after we make a new release at the end of the first week of April. PS: We should also get in touch with the FreeS/WAN fellows, and some other projects that could make use of our crypto. - k --=20 copyleft (c) 2002, Kyle McMartin |
|
From: Ben S. <sl...@st...> - 2002-03-25 01:22:47
|
Hm.. Looking at the SRPM, it seems that you've added SHA1 password hashing into the old util-linux-cryptoapi patch. Now it occurs to me: maybe instead of tacking hash algorithms onto util-linux, we might be better off sending the unhashed password into kernelspace, and let cryptoloop do the hashing itself. I can think of arguments for and against this. OOH, it seems like a bad idea to make the kernel do what can be (and is) done just fine in userspace. OTOH, we already have the digest algorithms in the kernel; it seems like a waste to recode them, especially in a _separate_ patch, and especially when the result is immediately handed off to cryptoloop. Thoughts? Flames? -- Ben Slusky | It is amazing how many eggs sl...@st... | one can break without making a sl...@pa... | decent omelette. PGP keyID ADA44B3B | -Charles P. Issawi |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-24 22:42:24
|
On Sun, 2002-03-24 at 22:13, Herbert Valerio Riedel wrote: > 3.) util-linux rh7.2 rpms for testing are available here: > http://www.ifs.tuwien.ac.at/~hvr/crypto/ >=20 > they haven't got much testing yet... so if there's anyone w/ redhat > machines... please test them! I've done some quick tests... it seems, that we can offer people who started using loop-AES a migration path to cryptoloop... e.g.; if you created your volumes w/ loop-AES w/ losetup-aes -e aes256 -H sha512 /dev/loop0 /dev/hde3 you can access that same volume w/ cryptoloop w/ losetup -e aes -k 256 -P sha512 /dev/loop0 /dev/hde3 ...a table for translating loop-AES' losetup options to cryptoapi's losetup options is below (haven't tested all yet!) loop-AES cryptoapi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -e aes128 -H rmd160 -e aes -k 128 -e aes128 -H sha256 -e aes -k 128 -P sha256 -e aes128 -H sha384 -e aes -k 128 -P sha384 -e aes128 -H sha512 -e aes -k 128 -P sha512 [...correspondig for 192 bit keylength...] -e aes256 -H rmd160 -e aes -k 256 -e aes256 -H sha256 -e aes -k 256 -P sha256 -e aes256 -H sha384 -e aes -k 256 -P sha384 -e aes256 -H sha512 -e aes -k 256 -P sha512 (and now the interesting part, when not specifying the -H option) -e aes128 -e aes -k 128 -P sha256 -e aes192 -e aes -k 192 -P sha384 -e aes256 -e aes -k 256 -P sha512 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-24 21:13:24
|
1.) the DFC cipher has been successfully verified against official test vectors (on IA32 at least, I'll test on ppc asap)! (thanks to gisle for sending them to me) 2.) so this leaves us w/ cipher-idea broken, and cipher-rc5 unverified... 3.) util-linux rh7.2 rpms for testing are available here: http://www.ifs.tuwien.ac.at/~hvr/crypto/ they haven't got much testing yet... so if there's anyone w/ redhat machines... please test them! 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-24 16:07:21
|
hello! just wanted to inform you, that I've made real the plan to import util-linux into cvs; you can get it through the 'util-linux' module; I've organized it that way, that the HEAD branch is the un-modified util-linux package, and for each util-linux version there's a cryptoapi enabled branch; at the moment, there's=20 the branch tag VER_2_11O_CRYPTO and the HEAD-tag VER_2_11O please don't commit anything to the util-linux module, unless you have experience w/ CVS wrt to branching&merging.... as that could lead to major headaches :-) to make it easier to start working w/ it; just do a=20 cvs get -r VER_2_11O_CRYPTO util-linux to get the crypto enabled mods; then you can also use 'cvs update' to get the latest changes in the current branch; but be sure, not to reset the sticky branch tag, otherwise you'll be thrown back to the HEAD branch... fyi, I've started work for adding a new --phash option to losetup/mount; ...this should bring us the feature to be able to access loop-AES created encrypted volumes....! :-) 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: Gisle S{l. <gi...@ii...> - 2002-03-23 17:34:13
|
On 23 Mar 2002, Herbert Valerio Riedel wrote: > On Thu, 2002-03-21 at 21:43, David Bryson wrote: > > hvr, can you give us a clue as to what/when this patch you want us to w= ait > > for is coming/is about ? > > it's in :-) > > ...check out the all new crypto/ciphers/gen-cipher.h template header! > > I've migrated all ciphers except rc5, idea and dfc... which brings me to > another topic _still_ unresolved :-/ > > ...we need to verify rc5, idea and dfc implementations...!! ;-) DFC definitly works. I tested it against the test vectors submited to NIST during the AES competition. RC5 and IDEA however, seems not to work. I did not have the same kind of official test vectors that I had for DFC, but failing on one test vector is almost certainly the same as a wringly implemened algorithm. I got the test vectors for idea and rc5 in 'Handbook of applied cryptography' (Menezes et al), but I'm not absolutly certain that the test vectors had the right parameterization for rc5 (but at least almost certain). This means that IDEA and RC5 probably don't work. I will bring out the latest version of the cryptoapi from CVS and test once more, since the one I used not was updated for a while. I should also mention that I tested the ciphers, not that they worked in a loopback context. > btw, the Config.help enhancements look nice... when can we get them in? > :-) > > regards, > --=20 -- Gisle S=E6lensminde ( gi...@ii... ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-23 15:05:41
|
On Thu, 2002-03-21 at 21:43, David Bryson wrote: > hvr, can you give us a clue as to what/when this patch you want us to wai= t > for is coming/is about ? it's in :-) ...check out the all new crypto/ciphers/gen-cipher.h template header! I've migrated all ciphers except rc5, idea and dfc... which brings me to another topic _still_ unresolved :-/ ...we need to verify rc5, idea and dfc implementations...!! ;-) btw, the Config.help enhancements look nice... when can we get them in? :-) 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 |
