On 2019-09-30 04:42:06 [+0200], Jason A. Donenfeld wrote:
> Hi Sebastian, Thomas,
Hi Jason,
> On Sun, Sep 29, 2019 at 7:39 PM Ard Biesheuvel
> wrote:
> > + for (;;) {
> > + const size_t blocks = min_t(size_t, nblocks,
> > + PAGE_SIZE /
* Herbert Xu | 2008-08-07 22:53:12 [+0800]:
>I've coded this up with the per-cpu structure and it seems to work.
yup, excellent. Thanks for finishing this. I had the following comment
above my DEFINE_PER_CPU definition (I replaced my definition with
last_cword):
|/*
| * PER-CPU last_cword is here
* David Woodhouse | 2008-08-04 11:12:05 [+0100]:
>On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
>> +u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
>> len)
>> +{
>> + unsigned int iquotient = len / SCALE_F;
>> + unsigned int iremainder = len % SCALE_F;
>>
* Neil Horman | 2008-07-03 22:10:28 [-0400]:
>On Fri, Jul 04, 2008 at 01:36:33AM +0200, Andi Kleen wrote:
>> Sebastian Siewior <[EMAIL PROTECTED]> writes:
>> >
>> > Anything wrong with get_random_bytes()?
>> > Whats the advantage over get_random_b
* Neil Horman | 2008-07-03 16:19:24 [-0400]:
>This patchset add a pseudo random number generator to the kernel crypto
>library.
>Usefull in assisting with the implementation of various FIPS compliant ipsec
>algorithms. Based on the suggestions provided in ANSI X9.31 Appendix A.2.4.
>Tested succe
* Geert Uytterhoeven | 2008-06-26 09:14:51 [+0200]:
>On Wed, 25 Jun 2008, Sebastian Siewior wrote:
>> see. Other zlib users like ppp or jffs2 user zlib directly. However, the
>> crypto API is the only place in kernel which provides you a generic
>> interface for compressio
* Geert Uytterhoeven | 2008-06-25 19:26:28 [+0200]:
> Hi,
Hello,
>
>I have a few questions about the "deflate" crypto module (crypto/deflate.c).
>
> 1. Why does it support decompression of full chunks only (i.e. all compressed
> data has to be passed at once)? Is there a specific reas
* Herbert Xu | 2008-05-26 21:05:08 [+1000]:
>Sebastian, if you're still seeing worse results on powerpc could you
>post the actual numbers with/without this patch?
le32:
~
|testing speed of rmd128
|test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):105
cycles/operation,6
* Adrian-Ken Rueegsegger | 2008-06-01 19:16:18 [+0200]:
>This patch fixes the usage of RIPEMD-160 in xfrm_algo which in turn
>allows hmac(rmd160) to be used as authentication mechanism in IPsec
>ESP and AH (see RFC 2857).
>
>Signed-off-by: Adrian-Ken Rueegsegger <[EMAIL PROTECTED]>
>---
> net/xfrm
* Herbert Xu | 2008-05-26 21:05:08 [+1000]:
>Sebastian, if you're still seeing worse results on powerpc could you
>post the actual numbers with/without this patch?
Sure. I test it around Monday.
>Thanks,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the b
* David Miller | 2008-05-21 00:11:42 [-0700]:
>From: Sebastian Siewior <[EMAIL PROTECTED]>
>Date: Wed, 21 May 2008 09:09:54 +0200
>
>> That was, what I expected as well but the numbers were different. I
>> checked the assembly code and I had the le loads but more
* David Miller | 2008-05-20 19:47:23 [-0700]:
>From: Herbert Xu <[EMAIL PROTECTED]>
I though you and Herbert are two different persons.
>Performance is significantly increased on Niagara2 by using
>the little-endian loads inside of the transformation loop, as
>expected. The numbers below are fi
* Adrian-Ken Rueegsegger | 2008-05-20 21:49:49 [+0200]:
>These patches fix the endian issues reported by Sebastian Siewior for
>the three remaining RIPEMD modules rmd160, rmd256 and rmd320.
>
> crypto/rmd160.c | 37 +
> crypto/
* Adrian-Ken R?egsegger | 2008-05-19 22:37:31 [+0200]:
>Sebastian Siewior wrote:
>> * Adrian-Ken Rueegsegger | 2008-05-18 23:35:55 [+0200]:
>>
>>> Sebastian, would you be so kind to test this patch on PowerPC?
>> Acked-by: Sebastian Siewior <[EMAIL PROTECTED]&
* Adrian-Ken Rueegsegger | 2008-05-18 23:35:55 [+0200]:
>Sebastian, would you be so kind to test this patch on PowerPC?
Acked-by: Sebastian Siewior <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EM
* Adrian-Ken Rueegsegger | 2008-05-18 23:35:55 [+0200]:
>I put the le32_to_cpu call in the ROUND-define so code-size is smaller
>compared to Sebastians patch. I also removed the three now obsolete
>functions (le32_to_cpu_array, cpu_to_le32_array and rmd_transform_helper),
>which makes the code sma
* David Miller | 2008-05-17 02:01:22 [-0700]:
>From: Sebastian Siewior <[EMAIL PROTECTED]>
>Date: Sat, 17 May 2008 10:47:35 +0200
>
>> David: would you please be so kind to run a test on sparc machine?
>
>How do I run the test?
modprobe tcrypt mode=314
do you need / w
* Herbert Xu | 2008-05-17 16:37:38 [+0800]:
>On Sat, May 17, 2008 at 10:27:54AM +0200, Sebastian Siewior wrote:
>>
>> I know that. Please see my follow up mail with some tiny numbers.
>> gcc-4.1.1 was used on a mpc8544.
>
>But what do the numbers look like on other arc
* David Miller | 2008-05-17 01:22:35 [-0700]:
>From: Sebastian Siewior <[EMAIL PROTECTED]>
>Date: Sat, 17 May 2008 10:10:03 +0200
>
>> +ROUND(aa, bb, cc, dd, F1, K1, le32_to_cpu(in[ 0]), 11);
>
>Not to nitpick, but if you use le32_to_cpup() this will allow the
* Sebastian Siewior | 2008-05-17 10:10:03 [+0200]:
>diff --git a/crypto/rmd128.c b/crypto/rmd128.c
>index 146a167..0d946a3 100644
>--- a/crypto/rmd128.c
>+++ b/crypto/rmd128.c
>-static inline void le32_to_cpu_array(u32 *buf, unsigned int words)
>-{
&g
Not everybody counts 10 as 01.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Changelog:
v2: state is now cpu endian and converted on final. This saves a few
cycles :)
v1: quick make it work
crypto/rmd128.c | 288 ++--
From: Sebastian Siewior <[EMAIL PROTECTED]>
Not everybody counts 10 as 01.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Adrian-Ken: I expect the other implementiation to be broken. Please fix
it :)
crypto/rmd128.c | 316 +++---
* Herbert Xu | 2008-05-14 19:03:11 [+0800]:
>On Wed, May 14, 2008 at 12:32:24PM +0200, Sebastian Siewior wrote:
>>
>> >This should add support for OpenSSL. Please note that user of this patch
>> >musts patch OpenSSL. The OpenSSL patch can be found in OCF-Linux as this
* Loc Ho | 2008-05-13 17:00:58 [-0700]:
>I am re-sending this email as I don't believe it got to the mailing
>list. Due to email problem, I am forward this patch on behalf of Shasi
>Pulijala who worked on this user space interface for Linux CryptoAPI.
If you forward patches, you should put your si
* Herbert Xu | 2008-05-06 18:28:15 [+0800]:
>Actually this just exposed an ancient bug in hmac. It relied
>on the key to be in identity-mapped memory which has never been
>guaranteed.
huh. Thanks Herbert. I haven't seen this on 32bit machine.
>Thanks,
Sebastian
--
To unsubscribe from this list
* Adrian-Ken R?egsegger | 2008-05-03 13:44:41 [+0200]:
>Sebastian Siewior wrote:
>Hello Sebastian,
Hello,
>Additionaly I just saw, that ecb(des) encryption test nr 5 passes but it
>seems that the setkey operation fails with:
>
>setkey() failed flags=100100
That is okey, th
fine.
>
>The issue seems to have come from commit
>de224c309b5631bdaae3fcd6880cfb93b52f5a53.
Is this a bisect result?
>
>I have tested 48c8949ea8460216783dd33640121187b9531b60 which does not
>contain this bug. It's just before the various tcrypt-changes from
>Sebastian Siewio
* Huang, Ying | 2008-04-25 11:11:17 [+0800]:
>Hi, Sebastian,
Hi Huang,
sorry for the delay.
>I changed the patches to group the read or write together instead of
>interleaving. Can you help me to test these new patches? The new patches
>is attached with the mail.
The new results are attached.
>
* Stefan Hellermann | 2008-02-24 12:54:20 [+0100]:
>Hello,
Hello,
>I'm got my Via Epia SN Board a few days ago and could test everything related
>to the
>padlock engine, I'm especially interested in the aes-{lrw,xts} combo, this
>doesn't work at
Cool,
>the moment (last tested with 2.6.25-rc1).
>From Sebastian Siewior <[EMAIL PROTECTED]> # This line is ignored.
Subject: [RFC] padlock aes, unification of setkey()
Hello Herbert,
I sit on those two since November. Back then Michal dropped me an email
and told me that he will test it and get back to me. This didn't happ
The key expansion routine could be get little more generic, become
a kernel doc entry and then get exported.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/aes_generic.c | 56 +
include/crypto/aes.h |8 +-
2 files c
Padlock AES' setkey routine is the same as exported by the generic
implementation. So we could use it.
Cc: Michal Ludvig <[EMAIL PROTECTED]>
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
drivers/crypto/Kconfig |1 +
drivers/crypto/pad
inter.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/tcrypt.c | 346 +--
1 files changed, 181 insertions(+), 165 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6b8315b..92ce78b 100644
--- a/crypto/tcrypt.c
+
other three test vectors are also the reverse.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/tcrypt.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 1ac6ecd..aae79e9 100644
--- a/crypto/tcrypt.h
+++ b/
Hello Herbert,
I noticed that the tcrypt module got really fat. Don't worry, it is still
less than the nvidia blob :)
Patch
- #1 replaces the memcpy of the struct to something that works with
pointers. I noticed that some tests failed without doing this.
- #2 is the big diet. A copy of the patch
* Andi Kleen | 2008-01-31 13:49:54 [+0100]:
>On Thursday 31 January 2008 13:48:34 Sebastian Siewior wrote:
>> * Andi Kleen | 2008-01-31 10:21:24 [+0100]:
>>
>> >FYI -- with a linus git kernel of yesterday or so I ran into a problem
>> >where
>> >one c
* Andi Kleen | 2008-01-31 10:21:24 [+0100]:
>FYI -- with a linus git kernel of yesterday or so I ran into a problem where
>one cipher module (CBC) was compiled in and the rest modular. dm_crypt
>could not resolve the cipher module until I turned it into a module.
and dm_crypt itself was a module
* Loc Ho | 2008-01-24 13:07:24 [-0800]:
>Is there a particular format for submitting patch?
Take a look on those two:
Documentation/SubmitChecklist
Documentation/SubmittingPatches
>
>-Loc
>
Sebastian
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a mess
* Loc Ho | 2008-01-21 17:29:13 [-0800]:
>If that is the case, then in order to fully support async hashing, I would
>need an async version of HASH interface and an async version of digest. Am I
>correct?
Yes. In case you support hmac+sha1 in HW and you don't do sha1 (as
digest) at all you could sk
Hello Herbert,
this is just for the protocol. If you build the two aes modules into
the kernel (1x asm + 1x generic) than the asm module is initialized
before the generic one and even before the crypto API itself. This was
allready the case before I started to dig around :)
This is currently not a
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/cbc.c | 22 +-
crypto/ecb.c |7 ---
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/crypto/cbc.c b/crypto/cbc.c
index a525dcc..15c8095 100644
--- a/crypto/cbc.c
+++ b/crypto
Software usually can't fail because they don't do anything
dangerous. However HW implementation could fail for $reason.
This patch changes the prototype and adjusts all ciphers. Most
of them return zero except s390 and geode since the HW provides
a return parameter.
Signed-off-by:
The return parameter isn't used remove it.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/x86/crypto/aes-i586-asm_32.S |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/x86/crypto/aes-i586-asm_32.S
b/arch/x86/crypto/aes-i586-asm_32.S
in
The speed templates as it look always the same. The key size
is repeated for each block size and we test always the same
block size. The addition of one inner loop makes it possible
to get rid of the struct and it is possible to use a tiny
u8 array :)
Signed-off-by: Sebastian Siewior <[EM
Some crypto ciphers which are impleneted support similar key sizes
(16,24 & 32 byte). They can be grouped together and use a common
templatte instead of their own which contains the same data.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/tcryp
Hello Herbert,
Patch 1 and 2 are shrinking the speed template a little. Did you had
something like this in mind?
Patch 3 removes the return parameter from the AES-i586 asm module
because it is unused anyway.
Patch 4 + 5 is not an attempt to touch as many file as possible but
something you aske
* Loc Ho | 2008-01-17 13:25:38 [-0800]:
>>Questions:
>>2. What is the difference between digest and hash type besides one
>>operation on transformation structure (tfm) and the other on descriptor
>(desc)?
>They are used for different things.
>Digest is something like sha1 or md5. You just feed yo
* Loc Ho | 2008-01-17 10:37:20 [-0800]:
>struct hash_alg {
> int (*init)(struct hash_desc *desc);
> int (*update)(struct hash_desc *desc, struct scatterlist *sg,
> unsigned int nbytes);
> int (*final)(struct hash_desc *desc, u8 *out);
> int (*digest)(str
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
* Herbert Xu | 2008-01-13 11:35:14 [+1100]:
>Applied to cryptodev-2.6. Thanks Sebastian.
could you please squash this one into :)
arch/x86/crypto/twofish_glue.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
dif
* Herbert Xu | 2008-01-12 11:57:42 [+1100]:
>
>Thanks for following this through!
np
>
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index 1ab8c01..a935abc 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -1705,6 +1705,12 @@ static void do_test(void)
>> test_c
There is almost no difference between 32 & 64 bit glue code.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Herbert, I wasn't able to compile / function test on 64bit but this
patch looks somehow trivial :)
arch/x86/crypto/Makefile |4 +-
* Andi Kleen | 2008-01-10 16:46:50 [+0100]:
>On Thu, Jan 10, 2008 at 02:35:29PM +0100, Sebastian Siewior wrote:
>> * Herbert Xu | 2008-01-10 20:27:46 [+1100]:
>>
>> >On Thu, Jan 10, 2008 at 10:25:55AM +0100, Andi Kleen wrote:
>> >>
>> >> Then
* Herbert Xu | 2008-01-10 20:27:46 [+1100]:
>On Thu, Jan 10, 2008 at 10:25:55AM +0100, Andi Kleen wrote:
>>
>> Then I don't think the patch should have been applied.
>
>I disagree. There isn't any evidence showing that the inlined version
>is significantly faster either. In the absence of that,
* Herbert Xu | 2008-01-08 17:13:50 [+1100]:
>On Sat, Jan 05, 2008 at 01:36:37PM +0100, Sebastian Siewior wrote:
>> and select the crypto subsystem if neccessary
>>
>> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
>
>Could you please resend this patch to Da
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/Kconfig |2 +-
crypto/Makefile|3 ++-
crypto/api.c |3 +++
include/linux/crypto.h |7 ---
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/crypto/Kconfig b/crypto/K
and select the crypto subsystem if neccessary
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
net/xfrm/Kconfig |1 +
net/xfrm/xfrm_algo.c |2 --
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 577a4f8..74ab643
Hello Herbert,
I grep'ed for CONFIG_CRYPTO and crypto_has_alg() users and noticed that
only xfrm_algo.c must be fixed (patch #1).
The second patch than groups the four files together to a module. I
didn't add MODULE_AUTHOR() because I did not know who it might be but I
guess it would be you :)
Se
ERROR: "crypto_aead_setauthsize" [crypto/tcrypt.ko] undefined!
ERROR: "crypto_alloc_aead" [crypto/tcrypt.ko] undefined!
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
* Tan Swee Heng | 2007-12-17 02:06:15 [+0800]:
>Hi Herbert, as mentioned some time ago, I don't have an x86-64. So
>please help me test it. Thanks!
I tested it and it passed 5 of 5 tests :)
>diff --git a/crypto/Kconfig b/crypto/Kconfig
>index 221356b..b0481f7 100644
>--- a/crypto/Kconfig
>+++ b/
* Tan Swee Heng | 2007-12-17 01:59:26 [+0800]:
>The salsa20_32.c file is renamed to salsa20_glue.c. This is done
git-format-patch -M produces a smaller patch because it can detect
renames. Just a note for the future :)
>diff --git a/arch/x86/crypto/salsa20_glue.c b/arch/x86/crypto/salsa20_glue.c
crypto_blkcipher_decrypt is wrong because it does not care about
the IV.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/s390/crypto/aes_s390.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/ae
crypto_blkcipher_decrypt is wrong because it does not care about
the IV.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
drivers/crypto/geode-aes.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
* Herbert Xu | 2007-12-08 09:46:41 [+0800]:
>On Fri, Dec 07, 2007 at 07:24:05PM +0100, Sebastian Siewior wrote:
>> Jan pointed this out to me and fixed it in the fallback code for s390
>> and now I remembered that this could also be fixed here :)
>>
>> Signed-off-by
* Tan Swee Heng | 2007-12-08 01:02:04 [+0800]:
>Hi Sebastian,
Hi,
>On Dec 6, 2007 5:49 AM, Sebastian Siewior <[EMAIL PROTECTED]> wrote:
>> The patch is a large one. Do you thing all those comments are requried
>> or helping to understand what is going on?
>Actually no,
* Sebastian Siewior | 2007-12-07 19:24:47 [+0100]:
>This is required for one or two crypto users in tree which
>chain the IV.
Snippets from tcrypt mode=200, before the patch:
| testing speed of cbc(aes) encryption
| test 5 (192 bit key, 16 byte blocks): 1 operation in 3109 cycles (16
This is required for one or two crypto users in tree which
chain the IV.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/s390/crypto/aes_s390.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_
This is required for one or two crypto users in tree which
chain the IV.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
drivers/crypto/geode-aes.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
Jan pointed this out to me and fixed it in the fallback code for s390
and now I remembered that this could also be fixed here :)
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
drivers/crypto/geode-aes.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff -
* Herbert Xu | 2007-12-04 12:10:35 [+1100]:
>However, could you please fix all the crypto users to select CRYPTO
>first? We can then do the modularisation for the next release.
I mailed two patches to netdev where modules where using crypto code and
were not selecting crypto in Kconfig. This is _n
* Sebastian Siewior | 2007-12-01 13:19:10 [+0100]:
>This patch makes the whole crypto API is modular.
Ups, I forgot to put a MODULE_VERSION("GPL") inside of the module.
Herbert, do you nack that patch due to non-sense or do you think that
this might be usefull and I should send a
This patch makes the whole crypto API is modular.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/Kconfig |2 +-
crypto/Makefile|3 ++-
include/linux/crypto.h |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
--- linux-2.6.orig/crypto/K
Some CPUs support only 128 bit keys in HW. This patch adds SW fallback
support for the other keys which may be required. The generic algorithm
(and the block mode) must be availble in case of a fallback.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Signed-off-by: Jan Glauber &
There is no reason to keep the IV in the private structre. Instead keep
just a pointer to make the patch smaller :)
This also remove a few memcpy()s
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
drivers/crypto/geode-aes.c |6 ++
drivers/crypto/geode-aes.h |2 +-
2
32 bit and 64 bit glue code is using (now) the same
piece code. This patch unifies them.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/x86/crypto/Makefile |4 +-
arch/x86/crypto/aes_32.c | 58 --
arch/x86/
* Herbert Xu | 2007-11-26 17:28:32 [+0800]:
>On Mon, Nov 26, 2007 at 10:25:21AM +0100, Sebastian Siewior wrote:
>>
>> I saw that you rebased your cryptodev tree but you did not include
>> this patch. Should I resend it?
>
>I had to check my archives to refresh my m
* Herbert Xu | 2007-11-11 09:18:56 [+0800]:
>On Sat, Nov 10, 2007 at 10:20:00PM +0100, Sebastian Siewior wrote:
>> * Herbert Xu | 2007-11-10 19:19:55 [+0800]:
>>
>> >On Sat, Nov 03, 2007 at 11:05:03AM +0100, Sebastian Siewior wrote:
>> >>
>
* Sebastian Siewior | 2007-11-15 22:23:35 [+0100]:
>There is no reason to keep the IV in the private structre.
>This also remove a few memcpy()s
>
>Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Hi Herbert,
I saw that you rebased your cryptodev tree but you did not
* Herbert Xu | 2007-11-16 10:08:51 [+0800]:
>On Thu, Nov 15, 2007 at 10:10:05PM +0100, Sebastian Siewior wrote:
>>
>> In this case, the s390 has the same bug (they copy the IV back after
>> blkcipher_walk_done()). Howevere it will probably never get triggered
>> because
* Herbert Xu | 2007-11-16 10:08:51 [+0800]:
>You must copy it back to allow chaining. Even when we go async
>someone may wish to chain. So in that sense you've just found a
>bug in the hifn driver :)
Not only in hfin. My SPU-AES has the same bug. Do you know someone who
wants to chain? I can rem
There is no reason to keep the IV in the private structre.
This also remove a few memcpy()s
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Herbert, could I please squash that one into the bad one so there are no
broken commits?
diff --git a/drivers/crypto/geode-aes.c b/drivers/
* Herbert Xu | 2007-11-14 22:22:53 [+0800]:
>Indeed the last call to blkcipher_walk_done will free the IV if
>we had to copy it due to an alignment mismatch. Since geode has
>an alignment of 16 bytes, that's almost a given.
Ach
>You could copy from/to desc->info instead which would solve the
>pr
* Jan Glauber | 2007-11-12 18:04:29 [+]:
>Sebastian, thanks for working on this! Do you know if I need other
>posted patches that are not yet in cryptodev-2.6 for this to work?
Nope I should work. I tested it on Herbert's cryptodev tree.
>I'm asking becuase I'm getting the following crash usi
Hello Herbert,
I just run in a bug which I caused. Actually I don't understand it at
all. The bad patch seems to be:
|75a8ae21dfd08f425b72906cc30b53103b2e5105 is first bad commit
| commit 75a8ae21dfd08f425b72906cc30b53103b2e5105
| Author: Sebastian Siewior <[EMAIL PROTECTED]>
| Date
Some CPUs support only 128 bit keys in HW. This patch adds SW fallback
support for the other keys which may be required. The generic algorithm
(and the block mode) must be availble in case of a fallback.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Jan, please I didn't ha
* Herbert Xu | 2007-11-10 19:31:30 [+0800]:
>On Sun, Nov 04, 2007 at 09:59:23PM +0100, Sebastian Siewior wrote:
>> The Geode AES crypto engine supports only 128 bit long key. This
>> patch adds fallback for other key sizes which are required by the
>> AES standard.
>
* Michal Ludvig | 2007-11-05 12:54:50 [+1300]:
> I'll test and get back to you.
thx.
>
>> I have one question regarding the size of the expanded key: You reserve
>> 64 * 4 bytes for each key but it seems that you use only 60 * 4 bytes.
>> Are the other bytes used by the hardware or did you alloca
* Herbert Xu | 2007-11-10 19:19:55 [+0800]:
>On Sat, Nov 03, 2007 at 11:05:03AM +0100, Sebastian Siewior wrote:
>>
>> static struct crypto_alg aes_alg = {
>> -.cra_name = "aes",
>> -.cra_driver_name=
* Herbert Xu | 2007-11-10 19:39:14 [+0800]:
>On Tue, Nov 06, 2007 at 02:30:40PM -0700, Jordan Crouse wrote:
>> On 06/11/07 21:01 +0100, Sebastian Siewior wrote:
>> > Currently the Geode AES module fails to encrypt or decrypt if
>> > the coherent bits are not set what i
* Herbert Xu | 2007-11-08 21:26:33 [+0800]:
>On Sun, Oct 28, 2007 at 01:30:09PM +0100, Sebastian Siewior wrote:
>>
>> The setkey() function can be shared with the generic algorithm.
>>
>> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
>
>Beautifu
TED]>
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
drivers/crypto/geode-aes.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index f2d4fba..0ca92d4 100644
--- a/drivers/crypto/geode-aes.c
+++ b/dr
* Jonathan Lynch | 2007-11-06 18:28:00 [+]:
>SHA-224 should be chosen as a hash algorithm when 112 bits of security
>strength is required.
Who uses such an algorithm (in terms of application)?
>diff -uprN -X linux-2.6.24-rc1-vanilla/Documentation/dontdiff
>linux-2.6.24-rc1-vanilla/crypto/tc
The Geode AES crypto engine supports only 128 bit long key. This
patch adds fallback for other key sizes which are required by the
AES standard.
Cc: Jordan Crouse <[EMAIL PROTECTED]>
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Herbert, as you suggested I splitted ciphe
The setkey() function can be shared with the generic algorithm.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/x86/crypto/aes-i586-asm_32.S | 89
arch/x86/crypto/aes_32.c | 461 +
crypto/Kconfig
32 bit and 64 bit glue code is using (now) the same
gleue code. Make it one.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/x86/crypto/Makefile |4 +-
arch/x86/crypto/aes_32.c | 58 --
arch/x86/crypto/{ae
Hello Herbert,
this patch series unifies the AES setkey function for the i586 asm code.
Now the glue code is equal for aes_{32|64} and can be shared as well.
Sebastian
--
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
Mor
NO other block mode is M by default.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
Herbert, please squash this one into the CTR patch and if you set
apply.whitespace strip
than the white space damage shoud be fixed by itself on your next
rebase :)
diff --git a/crypto/Kco
The setkey() function can be shared with the generic algorithm.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/x86/crypto/aes-x86_64-asm_64.S | 68
arch/x86/crypto/aes_64.c| 282 +--
crypto/K
looking now identical (except they are using different tables and
key).
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/aes_generic.c | 249 --
include/crypto/aes.h | 16 +++
2 files changed, 136 insertions(+), 129 deletions(
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
crypto/aes_generic.c | 325 +++---
1 files changed, 176 insertions(+), 149 deletions(-)diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
index 6683260..df8df4d 100644
--- a/
This is almost a repost of an earlier series. I got rid of the
aes_common module and the x86_64 selects the generic version.
Sebastian
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kerne
1 - 100 of 223 matches
Mail list logo
