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: Herbert V. R. <hv...@hv...> - 2002-03-23 15:01:07
|
On Fri, 2002-03-22 at 06:34, Kyle McMartin wrote: > > Is CryptoAPI in the US? > > Where is SourceForge, for that matter? > CryptoAPI is currently parked in the Sourceforge cvs servers, located at > VA Linux in Fremont, California. =20 > This subjects everyone who downloads cryptoapi to the United > Soviet State of Americas export law. =20 > I do not think this is a problem though, since there is alot of > crypto on sourceforge currently. =20 > I would however, like to know what hvr thinks of this. well... cryptoapi is also distributed through kernel.org; so I thought I wouldn't do major harm if I put that stuff on sourceforge.net as well; btw, kernel.org's motd for cryptography: This site includes publicly available encryption source code which, together with object code resulting from the compiling of publicly available source code, may be exported from the United States under License Exception "TSU" pursuant to 15 C.F.R. Section 740.13(e). anyway, since I'm living in austria, I'm a non-US citizen; should US laws ever change, I can easily migrate the code back to europe, where in originally was located... 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: mehul r. c. <meh...@re...> - 2002-03-22 05:40:32
|
hi friends, i am cryptography newbie. can u guys allocate small parts(assignments) to newbies like us so that we can R&D on it and gain knowledge. u guys are coding Crypto API, there can be small parts which u can give us as assignments. if anyone is annoyed with my ques. then i am really sorry. waiting for reply... mehul. |
|
From: Kyle M. <ky...@de...> - 2002-03-22 05:32:58
|
On Thu, Mar 21, 2002 at 11:20:21PM -0500, Ben Slusky wrote: > The question is whether CryptoAPI project is in some way "in" the US. > ISTR that the kerneli project was based somewhere else to avoid US > crypto regs (however easy they've become of late). >=20 > Is CryptoAPI in the US? > Where is SourceForge, for that matter? >=20 CryptoAPI is currently parked in the Sourceforge cvs servers, located at VA Linux in Fremont, California. This subjects everyone who downloads cryptoapi to the United Soviet State of Americas export law. I do not think this is a problem though, since there is alot of crypto on sourceforge currently. I would however, like to know what hvr thinks of this. Regards, Kyle --=20 copyleft (c) 2002, Kyle McMartin |
|
From: Ben S. <sl...@st...> - 2002-03-22 04:20:30
|
The question is whether CryptoAPI project is in some way "in" the US. ISTR that the kerneli project was based somewhere else to avoid US crypto regs (however easy they've become of late). Is CryptoAPI in the US? Where is SourceForge, for that matter? On Thu, 21 Mar 2002 20:09:28 -0700, David Bryson wrote: > So, I did a little research today on crypto laws for people in the US. > Turns out since our stuff is open source all we are "supposed" to do is > send a letter to the bureau of export administration telling them a few > things and a copy of the source code. I'm not sure if we even care about > this, personally i don't, i just thought i would look it up. > There was a section on working on crypto with people outside the US and > apparently that's OK too if it's open source. So i'm not seeing a whole > lot of problems here, it's just a question of whether we want to send them > a letter or not... suggestions, ideas, flames ? -- Ben Slusky | It was only after their population sl...@st... | of 50 mysteriously shrank to eight "will program for food" | that the other seven dwarfs began PGP keyID ADA44B3B | to suspect Hungry. |
|
From: David B. <db...@du...> - 2002-03-22 03:09:36
|
So, I did a little research today on crypto laws for people in the US. Turns out since our stuff is open source all we are "supposed" to do is send a letter to the bureau of export administration telling them a few things and a copy of the source code. I'm not sure if we even care about this, personally i don't, i just thought i would look it up. There was a section on working on crypto with people outside the US and apparently that's OK too if it's open source. So i'm not seeing a whole lot of problems here, it's just a question of whether we want to send them a letter or not... suggestions, ideas, flames ? Dave |
|
From: David B. <db...@du...> - 2002-03-21 22:42:52
|
Ok, updated a few things via suggestions by various folks on the ciphers Config.help, and created a Config.help for the digests. Again, comments/flames welcome. If there aren't any more glaring issues i'll commit these early next week. Dave on a side note i'm waiting back for an e-mail from the DFC people, i couldn't find information on what kind of license it has. |
|
From: David B. <db...@du...> - 2002-03-21 20:46:22
|
cool, Kyle also suggested a few things like: we reccomend nothing. w=
hich
i thought was a good policy to take. At anyrate, i'll change a few
things, and post it again for comments.
And i guess my own bias about DES(i don't like it one bit ;-) shouldn=
't
really be put in the briefs anyway.
hvr, can you give us a clue as to what/when this patch you want us to=
wait
for is coming/is about ?
Dave
On Thu, 21 Mar 2002, Gisle S{lensminde wrote:
> On Wed, 20 Mar 2002, David Bryson wrote:
>
> > I spent the last day or so collecting information on all of the c=
iphers so
> > that we could put some documentation in the "help" section of the=
configs.
> > Attached is my preliminary draft. Please look over it, find spel=
ling
> > errors, comment on it, change things. I'll try to get the digest=
s done
> > fairly soon as well.
> > Dave
> >
>
> Nice work. Here are some comments on the text:
>
> About AES/Rijndael:
>
> "It supports key sizes of 128, 192, and 256 bits which executes 9, =
11, and
> 13 rounds respectively."
>
> This is slightly wrong. The rijndael specification specifies 10, 12=
and 14
> rounds, 9, 11, and 13 ordinary round, and then one special last rou=
nd.
> This special last rounds are counted in the specification of the ci=
pher,
> so I think that it should be corrected.
>
> MARS/RC6:
>
> The IBM has patented MARS, but gives it for a royalies free license=
,
> even if it didn't won the AES competition, unlike RC6, where RSA s=
ecurity
> that only would give up their patent rights if they won. (Which was=
a
> reqirement for the candidates anyway). So you should also mention i=
t for
> RC6
>
> http://www.tivoli.com/news/press/pressreleases/en/2000/mars.html
>
> Serpent
>
> "Serpent was submitted as an AES candidate cipher coming in second =
place."
>
> This is not quite true, given that NIST only specified a winner, an=
d
> didn't rank the other 5 finalists. But the participants of the
> 3rd AES conference ranked it as no 2, and it's belived that
> it would won, if rijndael had been found unsuited for some reason.
> But NIST did not state this.
>
> DES:
>
> "This cipher was the first ever block cipher designed by Horst Fie=
stel
> which became DES(aka Lucifer)."
>
> Lucifer is the predecessor(s) of DES, rather than the same thing. T=
he
> candidate IBM gave to the NBS (predecessor of NIST), was modified b=
y NSA
> by changing the key schedule, and the sboxes. There was a lot of
> speculation of why they did so, but after diffencial cyptanalysis w=
as
> discovered by the sivil cryptographic community around 1990, it see=
med
> clear that the changes was to make the cipher resistent against
> differential cryptanalysis, and to reflect the effective keylength =
in the
> real keylength. I would rather write:
>
> "This cipher was designed by IBM and NSA based on the Lucifer ciphe=
r
> desigend by IBM"
>
> "It should be noted that DES is a older, slower, and insecure
> algorithm. We suggest you use one of the newer more secure ciphers
> with a larger key size."
>
> I would rather say something like:
>
> "It should be noted that DES has a keylength of only 56 bits, which
> is insufficient to provide real security today. We suggest you use =
one of
> the newer more secure ciphers ith a larger key size."
>
> 3DES:
>
> "This cipher is a modification of the DES algorithm which increases=
the
> keysize to 112-bits."
>
> It increases the keylength to 168 bits, but the best known
> attack has a complexity of 112 bits. If you change "keysize"
> "effective keysize" it will be more precise.
>
> "3DES is 3x slower than DES and provides minimal increase in securi=
ty."
>
> 3DES provides _much_ more security than DES. 3DES can't be broken
> today not even by NSA, unless they have some SCI-FI device in their
> basement. DES can be broken even by organizations with a limited
> budget, or groups of individuals on the net. In fact 3DES is rated
> as the most trustworthy cipher by many cryptographers, because
> it can rely on the security of DES, where most efficent attack
> is a brute force attack. The best known attack on 3DES is a meat in
> the middle attack with a work factor of 2^112 and a memory usage of
> 2^64. This is a comfortable margin to the minimum keylength even fo=
r
> longtime high security (which is 90 bits AFAIK). It better to just =
say
> it's slow.
>
>
>
> --
> 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)
>
>
> _______________________________________________
> CryptoAPI-devel mailing list
> Cry...@li...
> https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel
>
|
|
From: Gisle S{l. <gi...@ii...> - 2002-03-21 18:34:26
|
On Wed, 20 Mar 2002, David Bryson wrote: > I spent the last day or so collecting information on all of the ciphers s= o > that we could put some documentation in the "help" section of the configs= =2E > Attached is my preliminary draft. Please look over it, find spelling > errors, comment on it, change things. I'll try to get the digests done > fairly soon as well. > Dave > Nice work. Here are some comments on the text: About AES/Rijndael: "It supports key sizes of 128, 192, and 256 bits which executes 9, 11, and 13 rounds respectively." This is slightly wrong. The rijndael specification specifies 10, 12 and 14 rounds, 9, 11, and 13 ordinary round, and then one special last round. This special last rounds are counted in the specification of the cipher, so I think that it should be corrected. MARS/RC6: The IBM has patented MARS, but gives it for a royalies free license, even if it didn't won the AES competition, unlike RC6, where RSA security that only would give up their patent rights if they won. (Which was a reqirement for the candidates anyway). So you should also mention it for RC6 http://www.tivoli.com/news/press/pressreleases/en/2000/mars.html Serpent "Serpent was submitted as an AES candidate cipher coming in second place." This is not quite true, given that NIST only specified a winner, and didn't rank the other 5 finalists. But the participants of the 3rd AES conference ranked it as no 2, and it's belived that it would won, if rijndael had been found unsuited for some reason. But NIST did not state this. DES: "This cipher was the first ever block cipher designed by Horst Fiestel which became DES(aka Lucifer)." Lucifer is the predecessor(s) of DES, rather than the same thing. The candidate IBM gave to the NBS (predecessor of NIST), was modified by NSA by changing the key schedule, and the sboxes. There was a lot of speculation of why they did so, but after diffencial cyptanalysis was discovered by the sivil cryptographic community around 1990, it seemed clear that the changes was to make the cipher resistent against differential cryptanalysis, and to reflect the effective keylength in the real keylength. I would rather write: "This cipher was designed by IBM and NSA based on the Lucifer cipher desigend by IBM" "It should be noted that DES is a older, slower, and insecure algorithm. We suggest you use one of the newer more secure ciphers with a larger key size." I would rather say something like: "It should be noted that DES has a keylength of only 56 bits, which is insufficient to provide real security today. We suggest you use one of the newer more secure ciphers ith a larger key size." 3DES: "This cipher is a modification of the DES algorithm which increases the keysize to 112-bits." It increases the keylength to 168 bits, but the best known attack has a complexity of 112 bits. If you change "keysize" "effective keysize" it will be more precise. "3DES is 3x slower than DES and provides minimal increase in security." 3DES provides _much_ more security than DES. 3DES can't be broken today not even by NSA, unless they have some SCI-FI device in their basement. DES can be broken even by organizations with a limited budget, or groups of individuals on the net. In fact 3DES is rated as the most trustworthy cipher by many cryptographers, because it can rely on the security of DES, where most efficent attack is a brute force attack. The best known attack on 3DES is a meat in the middle attack with a work factor of 2^112 and a memory usage of 2^64. This is a comfortable margin to the minimum keylength even for longtime high security (which is 90 bits AFAIK). It better to just say it's slow. -- 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: Justin C. <ju...@po...> - 2002-03-21 01:57:31
|
Hi David, Now THAT is cool. (Herbert, do you think this information should also be extracted and put on the web-page?) :-) Regards and best wishes, Justin Clift David Bryson wrote: > > I spent the last day or so collecting information on all of the ciphers so > that we could put some documentation in the "help" section of the configs. > Attached is my preliminary draft. Please look over it, find spelling > errors, comment on it, change things. I'll try to get the digests done > fairly soon as well. > Dave > > ------------------------------------------------------------------------ > Name: Config.help > Config.help Type: Plain Text (TEXT/PLAIN) > Encoding: 7BIT -- "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-21 00:45:34
|
I spent the last day or so collecting information on all of the ciphers so that we could put some documentation in the "help" section of the configs. Attached is my preliminary draft. Please look over it, find spelling errors, comment on it, change things. I'll try to get the digests done fairly soon as well. Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-18 12:19:11
|
On Mon, 2002-03-18 at 09:47, David Bryson wrote: > So, I may have done something wrong, but the Config.help options are not > showing up on my kernel config. I was going to write > some help options for the different ciphers/digest, but the help that was > already there never showed up. > So, i started looking around for why they weren't on there and i ended up > not seeing any way to "register" the help file as a seperate place to loo= k > for help texts. afaict you just have to "cat crypto/Config.help > Documentation/Configure.help" ... which seems a little silly to me, can > anyone else shed some light on this for me? the Config.help file is there for 2.5's kbuild framework... I'm trying to use .diff files as little as possible, as they usually tend to create conflicts while patching, and require one to always maintain them... or to say in other words, they are a big mess... that's why I really like the 2.5 kbuild's idea of splitting up Configure.help; I hope that 2.4 gets this feature backported from 2.5.. or maybe we could could send in a patch to marcelo? anyway, in order to let this COnfig.help show up, you'll have to insert it into Documentation/Configure.help of your kernel source tree... this should be done from within the 'patch-kernel' makefile target... with some clever textutils aggregation... :-) > I also implemented gen-cfb today, so now we can use cipher feedback mode > for everything provided we put the includes in there. Which brings me to > my next question, could we just put #include "gen-<cipher>" in the > crypto.h instead of manually entering block modes into ever different > cipher? I want to implement a couple other block modes, pcbc, and ofb, > maybe some more. At any rate, we have to put new cipher contexts in ever= y > cipher.. so i was trying to figure out a way to try and abstract that a > bit. I'll poke around the sources some more, try to come up with ideas. I originally had plans to templatize the ciphers a bit more, but this'll have to wait a week... anyway, adding those includes into <crypto.h> is not such a good idea;=20 adding a local "gen-cipher.h" header (just where the gen-cbc.h and gen-ecb.h headers lay) is the way to go IMO; I'll commit something like that very soon... i.e. please don't do major modifications to the ciphers in CVS that I'll revert anyway... :-) 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-03-18 08:49:23
|
So, I may have done something wrong, but the Config.help options are not showing up on my kernel config. I was going to write some help options for the different ciphers/digest, but the help that was already there never showed up. So, i started looking around for why they weren't on there and i ended up not seeing any way to "register" the help file as a seperate place to look for help texts. afaict you just have to "cat crypto/Config.help Documentation/Configure.help" ... which seems a little silly to me, can anyone else shed some light on this for me? I also implemented gen-cfb today, so now we can use cipher feedback mode for everything provided we put the includes in there. Which brings me to my next question, could we just put #include "gen-<cipher>" in the crypto.h instead of manually entering block modes into ever different cipher? I want to implement a couple other block modes, pcbc, and ofb, maybe some more. At any rate, we have to put new cipher contexts in every cipher.. so i was trying to figure out a way to try and abstract that a bit. I'll poke around the sources some more, try to come up with ideas. Dave |
|
From: Kyle M. <ky...@de...> - 2002-03-17 22:09:33
|
has the loop-iv patch been integrated into 2.5? I think it would be a good thing to get done promptly. -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-15 07:22:13
|
another fwd... ---------- Forwarded message ---------- Date: Thu, 14 Mar 2002 20:57:42 -0500 From: Ben Slusky To: hv...@ke... Subject: [PATCH] trivial updates to cryptoapi-new This patch does two things: 1) Updates for 2.5 -- change MAJOR/MINOR to major/minor, if(need_resched) schedule() to cond_resched(). I had to include linux/sched.h at the beginning of cipher-rc5.c, it won't compile if you include it in the middle; all the others work fine tho'. 2) Add a target for 'install' in the Makefile, for those of us who build cryptoapi separately from the kernel tree. Useful feature -- I'm surprised that you haven't made more of it, especially considering how much Jari's been ragging on you in linux-crypto. I've got another patch that you might be interested in: a jari-over-hvr patch for 2.5. I've had my swap encrypted with cryptoapi for some time now, and it's no less stable than the rest of 2.5. Let me know if you want it. -- Ben Slusky | Integrity is the key. Once you sl...@st... | can fake that... "will program for food" | -Simon Travaglia PGP keyID ADA44B3B |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-15 07:17:30
|
fyi
--
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
---------- Forwarded message ----------
Date: Fri, 15 Mar 2002 00:57:19 +0200
From: Jari Ruusu <jar...@pp...>
To: Andrea Arcangeli <an...@su...>
Cc: Marcelo Tosatti <ma...@co...>,
Herbert Valerio Riedel <hv...@hv...>, lin...@vg...
Subject: Re: 2.4.19pre3aa2
Andrea Arcangeli wrote:
> Only in 2.4.19pre3aa2: 00_loop-IV-API-hvr-1
>
> Make the IV API not to be in function of the blkdev
> of the underlying fs, so you can copy your cryptoloop
> around without risking to lose data. This breaks the
> on-disk format of some encrypted transfer module though,
> if you don't like it please discuss it here in CC with
> Herbert Valerio Riedel <hv...@hv...>, the patch
> is from him. I think writing a converter in place of
> the loop data would be the preferred solution if needed. It could
> be done in a way to link transparently with the source of
> the kernel modules.
Since you are finally fixing loop bugs, attached is a patch of loop fixes
from loop-AES package (cipher code has been removed of course). These fixes
are well tested and are basically unchanged since September 29 2001. Biggest
fix is to make device backed loop work with swap so that encrypted swap is
possible:
- IV computed in 512 byte units.
- Make device backed loop work with swap by pre-allocating pages.
- External encryption module locking bug fixed (from Ingo Rohloff).
- Get rid of the loop_get_bs() crap.
- grab_cache_page() return value handled properly, avoids Oops.
- No more illegal messing with BH_Dirty flag.
- No more illegal sleeping in generic_make_request().
- Loops can be set-up properly when root partition is still mounted ro.
- Default soft block size is set properly for file backed loops.
- kmalloc() error case handled properly.
- loop_set_fd() 'goto out_putf' error case handled properly.
Regards,
Jari Ruusu <jar...@pp...>
|
|
From: Justin C. <ju...@po...> - 2002-03-14 00:55:43
|
Hi Kyle, Kyle McMartin wrote: > <snip> > i think we should convince Mr. Cox to added the IV patch to loop.c into > his -ac tree, hopefully to trickle into the main 2.4 tree. That sounds like a good idea. Let CryptoAPI into the kernel, a bit at a time. :) > also, i'm thinking we should seperate the distribution into patented and > unpatented ciphers, or rather, restricted and unrestricted, since i > doubt patented ciphers can go into a kernel :> Also sounds like another good idea. :-) Regards and best wishes, Justin Clift > > - k > > -- > copyleft (c) 2002, Kyle McMartin > > _______________________________________________ > CryptoAPI-devel mailing list > Cry...@li... > https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel -- "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-12 17:17:58
|
this was my attempt to come up with a mail that has a clever subject header. just to log what i've done recently: - CAST128 cipher support. - improvements to the Makefile system. - investigated some licensing. - began hunting for more test vectors. - more fixes which allow drop-in code for ciphers/digests. i think we should convince Mr. Cox to added the IV patch to loop.c into his -ac tree, hopefully to trickle into the main 2.4 tree. also, i'm thinking we should seperate the distribution into patented and unpatented ciphers, or rather, restricted and unrestricted, since i doubt patented ciphers can go into a kernel :> - k -- copyleft (c) 2002, Kyle McMartin |
|
From: Todd M. <nil...@ne...> - 2002-03-11 20:52:36
|
Not sure who the current maintainer of loop.c is, but I noticed that Jari has gotten some patches into loop.c over the past year, so he might have some more information, or perhaps he can get his patch submitted. Otherwise, you might try Alan Cox, he might be easier to get to accept the patch, and once it's in an ac kernel, it should eventually get pushed to mainline. Just some thoughts. On Fri, 2002-03-08 at 13:08, Herbert Valerio Riedel wrote: > well... > > alas I'm not very good in being convincing... :-( > > has anyone any idea how we can get marcelo to get the IV fix in? > otherwise I fear this issue will _never_ be fixed, and the iv patch will > have to exist until the year we make contact (2010)... :-/ > > regards, > > ---- > > From: Marcelo Tosatti <ma...@co...> > To: Herbert Valerio Riedel <hv...@ke...> > Subject: Re: [PATCH] loop-IV calculation fix > Date: 08 Mar 2002 13:47:28 -0300 > > > > On 6 Mar 2002, Herbert Valerio Riedel wrote: > > > On Wed, 2002-03-06 at 19:20, Marcelo Tosatti wrote: > > > Isnt the patch going to break old cryptoloop files? > > > > not really, since the 2.4 patch-int's cryptoloop files got broken > > anyway, due to this IV mess :-/ -- the patch-int requires this patch > > anyway to be applied, if you want to make use of the cryptoloop > > filter... > > > > most people using cryptoloop files already switched to the portable > > 512-byte IV metric, since it's the only sensible way to have reliable > > encrypted volumes with the 2.4 kernel series; > > Most people yes, but all people I don't think so, right ? > > I dont want those people to be unable to read their files. > > See? > > > > > > and the good thing is, that having the IV be of atomic size, we can > > easily emulate the 2.2 behaviour within the loop filter plugins for > > backward compatibility; > > > > if you want other opinions than mine, please ask andrea or axboe -- as > > we have discussed this issues since the beginnings of 2.4.x ... :-/ > > > > so the question is, shall we leave 2.4 broken, just because we want to > > keep compatibility which we lost anyway (to 2.2) or can we finally do > > the right thing (tm) and fix this bug? > > > > ps: it's quite easy to convert an old 2.2 style volume to a 512-byte > > metric volume... > > > > ps2: if you don't apply this patch, you can't even use some of the newer > > filesystems over cryptoloop... > |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-09 20:30:20
|
*) blowfish des des_ede3 aes mars serpent twofish rc6 -> verify ok against available test vectors on ia32 and ppc *) dfc rc5 -> no test vectors; but endian safe wrt ia32 and ppc *) idea=20 -> produces different results on big/little endian --=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...@ke...> - 2002-03-08 18:08:14
|
well... alas I'm not very good in being convincing... :-( has anyone any idea how we can get marcelo to get the IV fix in? otherwise I fear this issue will _never_ be fixed, and the iv patch will have to exist until the year we make contact (2010)... :-/ regards, |
|
From: Kyle M. <ky...@de...> - 2002-03-07 06:10:27
|
alright, i looked into test vectors and did some preliminary work on them. i also looked at writing the Documentation/cryptoapi.txt digests section and wrote a bit of it. also, the top level Makefile now uses your version target to grab the kernel version, so it is no longer necessary to define it. (i checked in the makefile solely) and with that, good night :) kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-05 17:47:40
|
fyi; I've checked in a few light modifications, which make the cryptoapi-core code compile against a 2.2.20 kernel; now there's just a loop patch needed... we should be able to simply use jari's 2.2 loop patch, and add the following lines to loop.h /* definitions for IV metric */ #define LOOP_IV_SECTOR_BITS 9 #define LOOP_IV_SECTOR_SIZE (1 << LOOP_IV_SECTOR_BITS) typedef int loop_iv_t; and then cryptoapi may work on 2.2 as well... (hint, need testers!) ps: any volunteer to take jari's loop-patches and extract everything except the ciphers (as done with the loop-jari-patch)? 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-05 12:37:11
|
Hi Herbert, Herbert Valerio Riedel wrote: > > On Tue, 5 Mar 2002, Justin Clift wrote: > > > 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. :) > ...silly me, the sigs can just be copied from kernel.org C:-) > > ...forget that argument... :) Heh Heh Heh That's alright. At least it means it won't be harder to give people the ability to verify the files they've got. :) > > there's only one thing now... the API changed a little bit for the > unofficial testing patches, and only now has changed back to a backward > compatible means... so please wait a little bit before adding files... Ummm... oops. I've just added most of them. Still wondering how I should put the loop-* files up, etc. What I've done so far is have add packages to the existing "cryptoapi" release. And each package is a group of files. i.e. : 2.4.18.1 patch-int-2.4.18.1.bz2 patch-int-2.4.18.1.bz2.sign patch-int-2.4.18.1.gz patch-int-2.4.18.1.gz.sign 2.4.18.0 patch-int-2.4.18.0.bz2 patch-int-2.4.18.0.bz2.sign patch-int-2.4.18.0.gz patch-int-2.4.18.0.gz.sign 2.4.17.0 patch-int-2.4.17.0.bz2 patch-int-2.4.17.0.bz2.sign patch-int-2.4.17.0.gz patch-int-2.4.17.0.gz.sign I'm thinking I should copy the loop-hvr-2.4.16.0.patch file to each of these, just because it'll make it easier for newcomers to understand, and probably the loop-jari-2.4.16.0.patch too. i.e. 2.4.18.1 loop-hvr-2.4.18.1.patch loop-jari-2.4.18.1.patch patch-int-2.4.18.1.bz2 patch-int-2.4.18.1.bz2.sign patch-int-2.4.18.1.gz patch-int-2.4.18.1.gz.sign 2.4.18.0 loop-hvr-2.4.18.0.patch loop-jari-2.4.18.0.patch patch-int-2.4.18.0.bz2 patch-int-2.4.18.0.bz2.sign patch-int-2.4.18.0.gz patch-int-2.4.18.0.gz.sign 2.4.17.0 loop-hvr-2.4.17.0.patch loop-jari-2.4.17.0.patch patch-int-2.4.17.0.bz2 patch-int-2.4.17.0.bz2.sign patch-int-2.4.17.0.gz patch-int-2.4.17.0.gz.sign Does adding in these patches (and renumbering them so it's easy to understand) make sense to you? :-) Regards and best wishes, Justin Clift > 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 -- "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-05 09:58:53
|
On Tue, 5 Mar 2002, Justin Clift wrote: > Just started adding the existing cryptoAPI patches to the "Files" > section of the Sourceforge project. oh... well... I should read emails more frequently... :-) 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 |
|
From: Herbert V. R. <hv...@hv...> - 2002-03-05 09:56:58
|
On Tue, 5 Mar 2002, Justin Clift wrote: > 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. :) ...silly me, the sigs can just be copied from kernel.org C:-) ...forget that argument... :) there's only one thing now... the API changed a little bit for the unofficial testing patches, and only now has changed back to a backward compatible means... so please wait a little bit before adding files... 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 |
