* 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;
+#ifdef
* 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_bytes()?
get_random_bytes() is not a _pseudo_ random number
* 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 compression.
Indeed. So if a hardware
* 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 reason for
* 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]
---
* 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
* 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 body
* 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 code. I will
check with different
* 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/rmd256.c | 37
* 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]
Sebastian, thanks for testing :)
You welcome
* 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
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 ++-
1 files
* 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
use of little-endian load instructions
* 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 architectures? In
particular, x86
* 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 / want the three patches or do you
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 +++
1 files
* 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:
* 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
* 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
interface uses the same I/O control
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 Siewior.
I tested it with tcrypt mode=0 what covers 100
* 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.
.
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
+++ b/crypto
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
, the 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/crypto
* 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?
* 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 cipher module (CBC) was compiled in and the rest modular
* 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 message
* 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 skip
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/tcrypt.c | 70
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 [EMAIL
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: Sebastian
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/cbc.c
* 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 your
* 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)(struct
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(-)
diff --git a/arch
* 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)
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 +-
arch/x86/crypto
* 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 David Miller and cc netdev?
yes, np
Sebastian
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 :)
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 100644
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/Kconfig
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 a/crypto/Kconfig b/crypto/Kconfig
* 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: Sebastian Siewior [EMAIL PROTECTED
* 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 an updated one
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/Kconfig
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 [EMAIL
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 files
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/crypto
* 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 they have an aligment of 0 (what
* 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 memory :)
OK I dropped it because:
: How
* 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
* 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
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/crypto
* 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 using
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 have the time
* 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 is currently the case
* 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= aes-x86_64,
+.cra_name = aes
* 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 allocate it
* 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]
Beautiful. All applied. Thanks Sebastian!
thx. There is also
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|1 +
3
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
are 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(-)diff --git
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/Kconfig b/crypto
From: Sebastian Siewior [EMAIL PROTECTED]
Share the tables and set_key function.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
crypto/Kconfig |1 +
crypto/aes_generic.c | 281 ++
2 files changed, 35 insertions(+), 247 deletions
From: Sebastian Siewior [EMAIL PROTECTED]
Share the tables and set_key function.
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/Kconfig
Hello Herbert,
this little patch series moves the the key generation routine and the four
tables which are used encrypt/decrypt function into a separate module.
Currently I converted the generic AES and the x86_64 variant. My 32bit asm
is rusted so the i586 assembly has to wait for a while :)
* Herbert Xu | 2007-10-21 16:31:58 [+0800]:
+if (type == CRYPTO_ALG_TYPE_BLKCIPHER) {
+op-fallback.blk = crypto_alloc_blkcipher(name, 0,
+CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
+
+} else if (type == CRYPTO_ALG_TYPE_CIPHER) {
+
This is a repost of an earlier patch series. I build it on top of cryptodev.
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.kernel.org/majordomo-info.html
From: Sebastian Siewior [EMAIL PROTECTED]
The code waits in a busy loop until the hardware finishes the encryption
or decryption process. This wants a cpu_relax() :)
The busy loop finishes either if the encryption is done or if the counter
is zero. If the latter is true than the hardware failed
From: Sebastian Siewior [EMAIL PROTECTED]
It is enough if the IV is copied before and after the while loop.
With DM-Crypt is seems not be required to save the IV after encrytion
because a new one is used in the request (dunno about other users).
It is not save to load the IV within while loop
* Krzysztof Oledzki | 2007-10-16 19:56:33 [+0200]:
After switching from i386 to x86_64 I noticed that /proc/crypto is much
shorter:
# wc -l /proc/crypto crypto-64
482 /proc/crypto
349 crypto-64
It is all fine from what I can see in this diff.
# diff -Nur /proc/crypto crypto-64
---
:)
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
drivers/crypto/geode-aes.c | 44 ++--
drivers/crypto/geode-aes.h |9 +++--
2 files changed, 25 insertions(+), 28 deletions(-)diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
drivers/crypto/geode-aes.c | 32
drivers/crypto/geode-aes.h | 36 ++--
2 files changed, 34 insertions(+), 34 deletions(-)diff --git a/drivers/crypto/geode-aes.c b/drivers
() statement to notice this.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
drivers/crypto/geode-aes.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 8bcd6d5..99ea594 100644
--- a/drivers/crypto
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.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
drivers/crypto/geode-aes.c | 188 +++-
drivers/crypto
This three defines are used in every AES related implementation.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
arch/i386/crypto/aes.c |4 +---
arch/s390/crypto/aes_s390.c |7 +--
arch/x86_64/crypto/aes.c |6 +-
crypto/aes.c |6
* Herbert Xu | 2007-10-11 19:47:00 [+0800]:
I'm not quite happy with adding keysize to the core API though.
At some point I'd like to see the DMA operations folded into the
API as well so having a key is going to be far from universal.
ACK
In fact the compression operation is an existing example
Hello Herbert,
this is my first attempt.
patch 1 - the main patch (touching core api)
patch 2 - fixing remaining crypto infrastructure
patch 3 - fixing some users
Almost all users are easy to fix. The wlan stack allocates the cipher at
one time and sets the key at another time. So I don't know
Add the keysize parameter to lookup functions within the core
crypto API.
---
crypto/algapi.c |7 +++--
crypto/api.c| 52 ++
crypto/cbc.c|2 +-
crypto/cryptomgr.c |3 +-
crypto/ecb.c|4
Fix the core crypto API and add keysize parameter.
---
crypto/authenc.c |7 ---
crypto/cbc.c |4 ++--
crypto/cryptd.c|8
crypto/cryptomgr.c |2 +-
crypto/hmac.c |4 ++--
crypto/lrw.c |4 ++--
crypto/pcbc.c |5 +++--
and fix dm-crypt, wlan stack and trcypt
---
crypto/tcrypt.c | 26 +++---
drivers/md/dm-crypt.c|2 +-
include/linux/crypto.h |6 +++---
net/ieee80211/ieee80211_crypt_tkip.c |4 ++--
.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
Herbert, with that patch tcrypt mode=200 works for lrw/xts again.
For some reason, the default tcrypt run fails for ecb(xtea) in
encryption test 3 only.
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 083d2e1..b7e4f05 100644
--- a/crypto
* Herbert Xu | 2007-10-08 11:15:10 [+0800]:
On Sat, Oct 06, 2007 at 11:58:57PM +0200, Sebastian Siewior wrote:
* Evgeniy Polyakov | 2007-10-02 19:00:13 [+0400]:
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Evgeniy Polyakov [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Driver for HIFN 795x crypto
* Herbert Xu | 2007-10-05 22:20:22 [+0800]:
On Fri, Oct 05, 2007 at 03:50:56PM +0200, Sebastian Siewior wrote:
I did not find a module_mutex. We hold a readlock of crypto_alg_sem
within the crypto subsystem and request_module() increments
kmod_concurrent (which may not exceed a certain limit
* Evgeniy Polyakov | 2007-10-02 19:00:13 [+0400]:
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Evgeniy Polyakov [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Driver for HIFN 795x crypto accelerator chip.);
Please also add MODULE_ALIAS for algos (that was aes, des and 3des as
far as I remember).
Sebastian
-
* Herbert Xu | 2007-10-05 23:10:51 [+0800]:
On Fri, Oct 05, 2007 at 03:12:10PM +0200, Sebastian Siewior wrote:
Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto
* Herbert Xu | 2007-10-05 16:57:44 [+0800]:
This patch is correct per se but it combined with the code in
padlock-sha can cause a dead-lock. Padlock-sha tries to load
the generic sha module in its init function. At this point it
is still holding the module_mutex so the probe will dead-lock.
I
Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED
as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
arch/s390/crypto/sha1_s390.c |2 +-
arch/s390/crypto/sha256_s390.c|2 +-
crypto/Makefile
* Herbert Xu | 2007-10-03 15:35:22 [+0800]:
On Sun, Sep 30, 2007 at 02:42:39PM +0200, Sebastian Siewior wrote:
Herbert, I tried to implement a MODULE_PRIO() macro which would be used
by the module loader and I noticed that it may not be required.
If there are two modules providing the same
* Herbert Xu | 2007-10-04 16:48:18 [+0800]:
On Thu, Oct 04, 2007 at 10:35:12AM +0200, Sebastian Siewior wrote:
Two last questions:
- What about the i386 assembly vs generic implementation? Do you prefer
the patch that I have send earlier (choose the assembly by default
making the generic
* Evgeniy Polyakov | 2007-10-02 19:00:13 [+0400]:
DES currently does not pass tcrypt's multipage test, since HIFN adapter
can not work with non-blocksize aligned chunks, although crypto alignmask
is set to 3, tcrypt provides a block of size 2 in its multipage test,
which fails.
I recalled now
* Evgeniy Polyakov | 2007-10-01 16:48:22 [+0400]:
Hello Evgeniy,
optimisations. It also refuses to register 'ecb(des)' with min and max
keylen set to the same number, so right now des and 3des are removed.
I don't know if I understood you correctly but keep this in mind:
min and max key size is
The compare code which looks for identical driver compares driver name
with algorithm name instead of driver name with driver name.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
Herbert, it looks like a typo to me. I'm not sure.
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -153,7
* Herbert Xu | 2007-08-20 20:06:05 [+0800]:
On Mon, Aug 20, 2007 at 12:16:18PM +0200, Andi Kleen wrote:
I don't think modprobe knows anything about these priorities.
Right, in that case we'd only load one of them, usually
the generic one since its name is what we're trying to
load.
But that
* Herbert Xu | 2007-09-20 08:20:58 [+0800]:
So that the generic C version can actually be tested on x86.
We don't want it to bit-rot which would make non-x86 2nd-class
citizens.
Okey. I try to post something what you might like in the new few days.
Cheers,
Sebastian
-
To unsubscribe from this
* Herbert Xu | 2007-09-19 20:29:43 [+0800]:
On Mon, Sep 03, 2007 at 12:42:27AM +0200, Sebastian Siewior wrote:
[crypto] do not use generic AES on i386 and x86_64
This patch automatically selects the assembly optimized version
of AES (if selected) and the generic version can no longer
Hi Rik,
I played with xts+dm-crypt on a 4GiB partition for a while and my box
did not hang.
I added some comments after init_tfm() where *I* think it is more
readable that way. Using ctx-tweak and ctx-child instead of child in
setkey() might be also better. However, this is my personal taste :)
* [EMAIL PROTECTED] | 2007-09-06 16:57:26 [+0200]:
The compiler should generate similar code.
I'd rather tell the compiler what I want than to introduce a new local
variable and a conditional branch in the hope that the compiler will
optimize it away, just to avoid a goto.
If you insist on
1 - 100 of 140 matches
Mail list logo
