Re: [RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
* 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/xfrm_algo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index ac765dd..23a2cc0 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -200,8 +200,8 @@ static struct xfrm_algo_desc aalg_list[] = {
}
},
{
- .name = hmac(ripemd160),
- .compat = ripemd160,
+ .name = hmac(rmd160),
+ .compat = rmd160,
On the other hand you could rename the algorithm itself couldn't you?
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
Re: [RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
Sebastian Siewior wrote:
* 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/xfrm_algo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index ac765dd..23a2cc0 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -200,8 +200,8 @@ static struct xfrm_algo_desc aalg_list[] = {
}
},
{
-.name = hmac(ripemd160),
-.compat = ripemd160,
+.name = hmac(rmd160),
+.compat = rmd160,
On the other hand you could rename the algorithm itself couldn't you?
Yes, that would be the other way to do it. Is there a preference or specific
reason
for renaming the hash algorithm than changing the reference to the algorithm?
Thanks,
Adrian
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
Re: [RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
On Mon, Jun 02, 2008 at 09:02:08AM +0200, Adrian-Ken Rueegsegger wrote:
Yes, that would be the other way to do it. Is there a preference or specific
reason
for renaming the hash algorithm than changing the reference to the algorithm?
I think the rmd name is fine. The existing entry in IPsec has
never worked (since we didn't have the implementation) so it
isn't an issue.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
Re: [RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
Herbert Xu wrote: On Mon, Jun 02, 2008 at 09:02:08AM +0200, Adrian-Ken Rueegsegger wrote: Yes, that would be the other way to do it. Is there a preference or specific reason for renaming the hash algorithm than changing the reference to the algorithm? I think the rmd name is fine. The existing entry in IPsec has never worked (since we didn't have the implementation) so it isn't an issue. Ok thanks for the clarification. I will resubmit the patch to the addresses you specified. I assume linux-crypto should also be cc'd? Adrian -- 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
Re: [RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
On Mon, Jun 02, 2008 at 09:09:40AM +0200, Adrian-Ken Rueegsegger wrote:
Ok thanks for the clarification. I will resubmit the patch to the addresses
you specified.
I assume linux-crypto should also be cc'd?
Yes please.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
Re: Crypto Fixes for 2.6.26
Hi Linus:
This push fixes a crash in CTS when SG debugging is enabled as
it doesn't set the debugging markers.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
Alexey Dobriyan (1):
[CRYPTO] cts: Init SG tables
crypto/cts.c |6 ++
1 file changed, 6 insertions(+)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Mon, Jun 02, 2008 at 12:43:46AM +0200, Adrian-Ken Rueegsegger wrote:
I just did a clean build on a different machine with the current HEAD
(ac3f925c2bb1b08a41713394d78098857d3f40a7)
of the cryptodev-2.6-tree. The two tests fail on that box too. :( I will see
if I can spot something suspicious by
comparing the two configs. Could somebody else run the tests and report back
the results?
It's failing for me on x86-64 as well.
Neil, I'm going to revert this until it's fixed. BTW, please
add the same tests to case 4 as well as case 0 so that we can run
the test by itself.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
[RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
This patch makes HMAC-RIPEMD-160 usable with IPsec/XFRM. The RIPEMD-160 implementation is currently in the cryptodev-2.6 tree. Since I have no IPsec test setup the patch has not (yet) been tested with IPsec and is thus marked as RFC. I will put together a test environment which will take some time. In the meantime it would be great if somebody who already has a working IPsec environment could test this patch. Thanks, Adrian -- 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
[RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
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/xfrm_algo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index ac765dd..23a2cc0 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -200,8 +200,8 @@ static struct xfrm_algo_desc aalg_list[] = {
}
},
{
- .name = hmac(ripemd160),
- .compat = ripemd160,
+ .name = hmac(rmd160),
+ .compat = rmd160,
.uinfo = {
.auth = {
--
1.5.2.5
--
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
BUG in scatterlist.h when loading tcrypt
Hi, i guess this shouldnt happen, got this when loading the tcrypt module [ 60.113277] testing ecb(seed) decryption across pages (chunking) [ 60.113309] [ 60.113311] testing cts(cbc(aes)) encryption [ 60.120984] test 1 (128 bit key): [ 60.121153] [ cut here ] [ 60.121312] kernel BUG at include/linux/scatterlist.h:65! [ 60.121446] invalid opcode: [#1] PREEMPT DEBUG_PAGEALLOC [ 60.121828] Modules linked in: tcrypt(+) [ 60.122019] [ 60.122019] Pid: 4100, comm: modprobe Not tainted (2.6.26-rc4-00103-g1beee8d #7) [ 60.122019] EIP: 0060:[c043feb0] EFLAGS: 00010216 CPU: 0 [ 60.122019] EIP is at cts_cbc_encrypt+0x2f0/0x300 [ 60.122019] EAX: c11808e0 EBX: 0010 ECX: c1002000 EDX: c11813c0 [ 60.122019] ESI: cbd4a5a0 EDI: cbf47bc0 EBP: cbf47c7c ESP: cbf47b3c [ 60.122019] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 60.122019] Process modprobe (pid: 4100, ti=cbf47000 task=cbf0ef20 task.ti=cbf47000) [ 60.122019] Stack: 0011 0046 0001 0046 c0a2c4c0 cbf47b60 [ 60.122019]c01464ad cbf47b9c 0046 0046 cbf47b8c c014048e cbf47ba4 [ 60.122019]00014f76 6f772049 20646c75 656b696c 65687420 0020 [ 60.122019] Call Trace: [ 60.122019] [c01464ad] ? put_lock_stats+0xd/0x30 [ 60.122019] [c014048e] ? getnstimeofday+0x3e/0x100 [ 60.122019] [c013e26e] ? hrtimer_interrupt+0x15e/0x190 [ 60.122019] [c01884c1] ? check_bytes_and_report+0x21/0xc0 [ 60.122019] [c01881a3] ? slab_pad_check+0x73/0x110 [ 60.122019] [c01898e3] ? __slab_free+0x63/0x2e0 [ 60.122019] [c043ff9e] ? crypto_cts_encrypt+0xde/0x100 [ 60.122019] [c0433085] ? setkey+0xc5/0xf0 [ 60.122019] [c0433978] ? async_encrypt+0x38/0x50 [ 60.122019] [d0aab5a5] ? test_cipher+0x215/0x840 [tcrypt] [ 60.122019] [c014048e] ? getnstimeofday+0x3e/0x100 [ 60.122019] [c0143649] ? clockevents_program_event+0x99/0x110 [ 60.122019] [c0144622] ? tick_program_event+0x42/0x70 [ 60.122019] [c013e26e] ? hrtimer_interrupt+0x15e/0x190 [ 60.122019] [c0103e57] ? restore_nocheck+0x12/0x15 [ 60.122019] [d0abea40] ? tcrypt_mod_init+0x1a40/0x1bf4 [tcrypt] [ 60.122019] [c013ef6a] ? blocking_notifier_call_chain+0x1a/0x20 [ 60.122019] [c0150cfe] ? sys_init_module+0xee/0x18e0 [ 60.122019] [c0167e44] ? unlock_page+0x24/0x30 [ 60.122019] [c018ad10] ? __kmalloc+0x0/0x100 [ 60.122019] [c0103d6d] ? sysenter_past_esp+0x6a/0xb1 [ 60.122019] === [ 60.122019] Code: 0b eb fe 0f 0b eb fe 8d 74 26 00 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d 74 26 00 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d 74 26 00 0f 0b eb fe 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 e5 83 ec [ 60.122019] EIP: [c043feb0] cts_cbc_encrypt+0x2f0/0x300 SS:ESP 0068:cbf47b3c [ 60.174099] ---[ end trace 4865479eed551e02 ]--- easily reproducible, but stack strace looks a bit different [ 353.926510] [ 353.926512] testing ecb(seed) decryption across pages (chunking) [ 353.926540] [ 353.926542] testing cts(cbc(aes)) encryption [ 353.930471] test 1 (128 bit key): [ 353.930603] [ cut here ] [ 353.930758] kernel BUG at include/linux/scatterlist.h:65! [ 353.930890] invalid opcode: [#1] PREEMPT DEBUG_PAGEALLOC [ 353.931017] Modules linked in: tcrypt(+) [ 353.931017] [ 353.931017] Pid: 4391, comm: modprobe Not tainted (2.6.26-rc4-00103-g1beee8d #7) [ 353.931017] EIP: 0060:[c043feb0] EFLAGS: 00010216 CPU: 0 [ 353.931017] EIP is at cts_cbc_encrypt+0x2f0/0x300 [ 353.931017] EAX: c1181f00 EBX: 0010 ECX: c1002000 EDX: c113a600 [ 353.931017] ESI: cf3fb480 EDI: cbff8bc0 EBP: cbff8c7c ESP: cbff8b3c [ 353.931017] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 353.931017] Process modprobe (pid: 4391, ti=cbff8000 task=cbecafa0 task.ti=cbff8000) [ 353.931017] Stack: 0011 37318b74 39333034 c08a4261 cfae50b8 005a 0008 [ 353.931017]c09b7160 cbff8b74 0001 c11f7c80 cfae4c90 c11f7c80 cbff8bac c0189336 [ 353.931017]0001 6f772049 20646c75 656b696c 65687420 0020 [ 353.931017] Call Trace: [ 353.931017] [c0189336] ? __slab_alloc+0x86/0x5d0 [ 353.931017] [c0755579] ? _spin_unlock_irqrestore+0x39/0x70 [ 353.931017] [c0127bcb] ? release_console_sem+0x1bb/0x1e0 [ 353.931017] [c01884c1] ? check_bytes_and_report+0x21/0xc0 [ 353.931017] [c01881a3] ? slab_pad_check+0x73/0x110 [ 353.931017] [c01898e3] ? __slab_free+0x63/0x2e0 [ 353.931017] [c043ff9e] ? crypto_cts_encrypt+0xde/0x100 [ 353.931017] [c0433085] ? setkey+0xc5/0xf0 [ 353.931017] [c0433978] ? async_encrypt+0x38/0x50 [ 353.931017] [d0aab5a5] ? test_cipher+0x215/0x840 [tcrypt] [ 353.931017] [d0aaa55a] ? test_hash+0x1fa/0x4f0 [tcrypt] [ 353.931017] [d0abea40] ? tcrypt_mod_init+0x1a40/0x1bf4 [tcrypt] [ 353.931017] [c013ef6a] ? blocking_notifier_call_chain+0x1a/0x20 [ 353.931017] [c0150cfe] ? sys_init_module+0xee/0x18e0 [ 353.931017] [c0167e44]
Re: [RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
On Mon, Jun 02, 2008 at 11:33:09AM +0200, Adrian-Ken Rueegsegger wrote:
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]
Acked-by: Herbert Xu [EMAIL PROTECTED]
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
Re: BUG in scatterlist.h when loading tcrypt
Hi. On Mon, Jun 02, 2008 at 11:08:59AM +0200, Eric Sesterhenn ([EMAIL PROTECTED]) wrote: i guess this shouldnt happen, got this when loading the tcrypt module [ 60.113277] testing ecb(seed) decryption across pages (chunking) [ 60.113309] [ 60.113311] testing cts(cbc(aes)) encryption [ 60.120984] test 1 (128 bit key): [ 60.121153] [ cut here ] [ 60.121312] kernel BUG at include/linux/scatterlist.h:65! Fix will be in Linus' tree soon, Herbert just pushed it upstream. http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;h=c4913c7b71abc79b008a3c118628cfb59bdb0efc -- Evgeniy Polyakov -- 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
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Mon, Jun 02, 2008 at 06:32:10PM +1000, Herbert Xu wrote:
On Mon, Jun 02, 2008 at 12:43:46AM +0200, Adrian-Ken Rueegsegger wrote:
I just did a clean build on a different machine with the current HEAD
(ac3f925c2bb1b08a41713394d78098857d3f40a7)
of the cryptodev-2.6-tree. The two tests fail on that box too. :( I will
see if I can spot something suspicious by
comparing the two configs. Could somebody else run the tests and report
back the results?
It's failing for me on x86-64 as well.
Neil, I'm going to revert this until it's fixed. BTW, please
add the same tests to case 4 as well as case 0 so that we can run
the test by itself.
Thanks,
Copy that. I think I found the problem, anyway. The verdict is that Adrian was
right, and I'm klutz. I mixed up the output vector from a successful and a
failed test during development. I'll repost shortly. Sorry for the trouble!
Regards
Neil
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
/
* Neil Horman [EMAIL PROTECTED]
* Software Engineer, Red Hat
/
--
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
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
Copy that. I think I found the problem, anyway. The verdict is that Adrian
was
right, and I'm klutz. I mixed up the output vector from a successful and a
failed test during development. I'll repost shortly. Sorry for the trouble!
No worries.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Mon, Jun 02, 2008 at 10:48:48PM +1000, Herbert Xu wrote:
On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
Copy that. I think I found the problem, anyway. The verdict is that
Adrian was
right, and I'm klutz. I mixed up the output vector from a successful and a
failed test during development. I'll repost shortly. Sorry for the
trouble!
No worries.
Ok, corrected the broken output vector and retested _several_ times. Also added
to test case 4 as requested. Sorry again for the trouble
Patch to add checking of DES3 test vectors using CBC mode. FIPS-140-2
compliance mandates that any supported mode of operation must include a self
test. This satisfies that requirement for cbc(des3_ede). The included test
vector was generated by me using openssl. Key/IV was generated with the
following command:
openssl enc -des_ede_cbc -P
input and output values were generated by repeating the string Too many
secrets a few times over, truncating it to 128 bytes, and encrypting it
with
openssl using the aformentioned key. Tested successfully by myself
Signed-off-by: Neil Horman [EMAIL PROTECTED]
tcrypt.c | 16 ++
tcrypt.h | 93 ---
2 files changed, 106 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6beabc5..30cd541 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1180,6 +1180,14 @@ static void do_test(void)
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
+
test_hash(md4, md4_tv_template, MD4_TEST_VECTORS);
test_hash(sha224, sha224_tv_template, SHA224_TEST_VECTORS);
@@ -1390,6 +1398,14 @@ static void do_test(void)
DES3_EDE_ENC_TEST_VECTORS);
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
break;
case 5:
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 47bc0ec..aaff76f 100644
--- a/crypto/tcrypt.h
+++ b/crypto/tcrypt.h
@@ -1442,6 +1442,8 @@ static struct hash_testvec hmac_sha512_tv_template[] = {
#define DES_CBC_DEC_TEST_VECTORS 4
#define DES3_EDE_ENC_TEST_VECTORS 3
#define DES3_EDE_DEC_TEST_VECTORS 3
+#define DES3_EDE_CBC_ENC_TEST_VECTORS 1
+#define DES3_EDE_CBC_DEC_TEST_VECTORS 1
static struct cipher_testvec des_enc_tv_template[] = {
{ /* From Applied Cryptography */
@@ -1680,9 +1682,6 @@ static struct cipher_testvec des_cbc_dec_tv_template[] = {
},
};
-/*
- * We really need some more test vectors, especially for DES3 CBC.
- */
static struct cipher_testvec des3_ede_enc_tv_template[] = {
{ /* These are from openssl */
.key= \x01\x23\x45\x67\x89\xab\xcd\xef
@@ -1745,6 +1744,94 @@ static struct cipher_testvec des3_ede_dec_tv_template[]
= {
},
};
+static struct cipher_testvec des3_ede_cbc_enc_tv_template[] = {
+ { /* Generated from openssl */
+ .key= \xE9\xC0\xFF\x2E\x76\x0B\x64\x24
+ \x44\x4D\x99\x5A\x12\xD6\x40\xC0
+ \xEA\xC2\x84\xE8\x14\x95\xDB\xE8,
+ .klen = 24,
+ .iv = \x7D\x33\x88\x93\x0F\x93\xB2\x42,
+ .input = \x6f\x54\x20\x6f\x61\x4d\x79\x6e
+ \x53\x20\x63\x65\x65\x72\x73\x74
+ \x54\x20\x6f\x6f\x4d\x20\x6e\x61
+ \x20\x79\x65\x53\x72\x63\x74\x65
+ \x20\x73\x6f\x54\x20\x6f\x61\x4d
+ \x79\x6e\x53\x20\x63\x65\x65\x72
+ \x73\x74\x54\x20\x6f\x6f\x4d\x20
+ \x6e\x61\x20\x79\x65\x53\x72\x63
+ \x74\x65\x20\x73\x6f\x54\x20\x6f
+ \x61\x4d\x79\x6e\x53\x20\x63\x65
+ \x65\x72\x73\x74\x54\x20\x6f\x6f
+ \x4d\x20\x6e\x61\x20\x79\x65\x53
+ \x72\x63\x74\x65\x20\x73\x6f\x54
+ \x20\x6f\x61\x4d\x79\x6e\x53\x20
+ \x63\x65\x65\x72\x73\x74\x54\x20
+
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, 2 Jun 2008 20:00:12 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: I meant descriptor hdr value accessed via it - can it be checked in tasklet under the lock and in submit path without? Can they correlate somehow? I believe the check for a non-null request-desc (under lock) before the hdr value is accessed ensures this doesn't happen. But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. can you point where in the code your concern is? desc is assigned under head lock and cleared under tail lock, both after an smp_wmb. hdr data is assigned before desc is written, and read after desc is found to be !NULL (i.e, hdr access is governed by if (desc)). head and tail indices get advanced each within their corresponding locks. So afaict there shouldn't be a case where data pointed to by desc can be accessed by both the consumer and the producer at any one point in time. Does that help? Kim -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. can you point where in the code your concern is? talitos_submit() writes to hdr (initially I think?) without locks. It is read in flush_channel() under tail lock, but then it is dropped, so I rised a question, if it can be modified during that time, since if it can, status value, calculated from it, can be different and thus error check result can be false. Or this is not an issue? -- Evgeniy Polyakov -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, 2 Jun 2008 21:57:51 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. can you point where in the code your concern is? talitos_submit() writes to hdr (initially I think?) without locks. ok, the desc whose hdr is being written was allocated by talitos_submit's caller, and it hasn't been made part of the circular buffer at that point. It becomes a part of the buffer (eligible for contention with the consumer side) when desc is assigned. It is read in flush_channel() under tail lock, but then it is dropped, so I rised a question, if it can be modified during that time, since if it can, status value, calculated from it, can be different and thus error check result can be false. Or this is not an issue? it would be an issue if flush_cannel didn't save off the data required to call the callback with in saved_req. flush_channel does this on purpose to be able to call the callback outside of lock (as is commented). Note desc gets assigned NULL prior to releasing the lock, after copying its contents to saved_req. Kim -- 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
Re: [PATCH v2] crypto: rmd128: make it work on my prefered architecture
* 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 cycles/byte |test 1 ( 64 byte blocks, 16 bytes per update, 4 updates):201 cycles/operation,3 cycles/byte |test 2 ( 64 byte blocks, 64 bytes per update, 1 updates):161 cycles/operation,2 cycles/byte |test 3 ( 256 byte blocks, 16 bytes per update, 16 updates):519 cycles/operation,2 cycles/byte |test 4 ( 256 byte blocks, 64 bytes per update, 4 updates):365 cycles/operation,1 cycles/byte |test 5 ( 256 byte blocks, 256 bytes per update, 1 updates):329 cycles/operation,1 cycles/byte |test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 1798 cycles/operation,1 cycles/byte |test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 1038 cycles/operation,1 cycles/byte |test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates):994 cycles/operation,0 cycles/byte |test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 3503 cycles/operation,1 cycles/byte |test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 1981 cycles/operation,0 cycles/byte |test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 1896 cycles/operation,0 cycles/byte |test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 1881 cycles/operation,0 cycles/byte |test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 6914 cycles/operation,1 cycles/byte |test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 3870 cycles/operation,0 cycles/byte |test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 3698 cycles/operation,0 cycles/byte |test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 3654 cycles/operation,0 cycles/byte |test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 13736 cycles/operation,1 cycles/byte |test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 7649 cycles/operation,0 cycles/byte |test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 7305 cycles/operation,0 cycles/byte |test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 7215 cycles/operation,0 cycles/byte |test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 7210 cycles/operation,0 cycles/byte | |testing speed of rmd160 |test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):144 cycles/operation,9 cycles/byte |test 1 ( 64 byte blocks, 16 bytes per update, 4 updates):276 cycles/operation,4 cycles/byte |test 2 ( 64 byte blocks, 64 bytes per update, 1 updates):237 cycles/operation,3 cycles/byte |test 3 ( 256 byte blocks, 16 bytes per update, 16 updates):706 cycles/operation,2 cycles/byte |test 4 ( 256 byte blocks, 64 bytes per update, 4 updates):552 cycles/operation,2 cycles/byte |test 5 ( 256 byte blocks, 256 bytes per update, 1 updates):517 cycles/operation,2 cycles/byte |test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 2432 cycles/operation,2 cycles/byte |test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 1671 cycles/operation,1 cycles/byte |test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 1628 cycles/operation,1 cycles/byte |test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 4731 cycles/operation,2 cycles/byte |test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 3211 cycles/operation,1 cycles/byte |test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 3124 cycles/operation,1 cycles/byte |test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 3109 cycles/operation,1 cycles/byte |test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 9332 cycles/operation,2 cycles/byte |test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 6290 cycles/operation,1 cycles/byte |test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 6116 cycles/operation,1 cycles/byte |test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 6072 cycles/operation,1 cycles/byte |test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 18532 cycles/operation,2 cycles/byte |test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 12450 cycles/operation,1 cycles/byte |test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 12102 cycles/operation,1 cycles/byte |test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 12011 cycles/operation,1 cycles/byte |test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 12006
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
Neil Horman wrote:
On Mon, Jun 02, 2008 at 10:48:48PM +1000, Herbert Xu wrote:
On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
Copy that. I think I found the problem, anyway. The verdict is that
Adrian was
right, and I'm klutz. I mixed up the output vector from a successful and a
failed test during development. I'll repost shortly. Sorry for the
trouble!
No worries.
Ok, corrected the broken output vector and retested _several_ times. Also
added
to test case 4 as requested. Sorry again for the trouble
Thanks a lot for clearing this up! I don't know if this is appropriate but in
any case:
Acked-by: Adrian-Ken Rueegsegger [EMAIL PROTECTED]
Adrian
Patch to add checking of DES3 test vectors using CBC mode. FIPS-140-2
compliance mandates that any supported mode of operation must include a
self
test. This satisfies that requirement for cbc(des3_ede). The included
test
vector was generated by me using openssl. Key/IV was generated with the
following command:
openssl enc -des_ede_cbc -P
input and output values were generated by repeating the string Too many
secrets a few times over, truncating it to 128 bytes, and encrypting it
with
openssl using the aformentioned key. Tested successfully by myself
Signed-off-by: Neil Horman [EMAIL PROTECTED]
tcrypt.c | 16 ++
tcrypt.h | 93
---
2 files changed, 106 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6beabc5..30cd541 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1180,6 +1180,14 @@ static void do_test(void)
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
+
test_hash(md4, md4_tv_template, MD4_TEST_VECTORS);
test_hash(sha224, sha224_tv_template, SHA224_TEST_VECTORS);
@@ -1390,6 +1398,14 @@ static void do_test(void)
DES3_EDE_ENC_TEST_VECTORS);
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
break;
case 5:
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 47bc0ec..aaff76f 100644
--- a/crypto/tcrypt.h
+++ b/crypto/tcrypt.h
@@ -1442,6 +1442,8 @@ static struct hash_testvec hmac_sha512_tv_template[] = {
#define DES_CBC_DEC_TEST_VECTORS 4
#define DES3_EDE_ENC_TEST_VECTORS3
#define DES3_EDE_DEC_TEST_VECTORS3
+#define DES3_EDE_CBC_ENC_TEST_VECTORS1
+#define DES3_EDE_CBC_DEC_TEST_VECTORS1
static struct cipher_testvec des_enc_tv_template[] = {
{ /* From Applied Cryptography */
@@ -1680,9 +1682,6 @@ static struct cipher_testvec des_cbc_dec_tv_template[]
= {
},
};
-/*
- * We really need some more test vectors, especially for DES3 CBC.
- */
static struct cipher_testvec des3_ede_enc_tv_template[] = {
{ /* These are from openssl */
.key= \x01\x23\x45\x67\x89\xab\xcd\xef
@@ -1745,6 +1744,94 @@ static struct cipher_testvec
des3_ede_dec_tv_template[] = {
},
};
+static struct cipher_testvec des3_ede_cbc_enc_tv_template[] = {
+ { /* Generated from openssl */
+ .key= \xE9\xC0\xFF\x2E\x76\x0B\x64\x24
+ \x44\x4D\x99\x5A\x12\xD6\x40\xC0
+ \xEA\xC2\x84\xE8\x14\x95\xDB\xE8,
+ .klen = 24,
+ .iv = \x7D\x33\x88\x93\x0F\x93\xB2\x42,
+ .input = \x6f\x54\x20\x6f\x61\x4d\x79\x6e
+ \x53\x20\x63\x65\x65\x72\x73\x74
+ \x54\x20\x6f\x6f\x4d\x20\x6e\x61
+ \x20\x79\x65\x53\x72\x63\x74\x65
+ \x20\x73\x6f\x54\x20\x6f\x61\x4d
+ \x79\x6e\x53\x20\x63\x65\x65\x72
+ \x73\x74\x54\x20\x6f\x6f\x4d\x20
+ \x6e\x61\x20\x79\x65\x53\x72\x63
+ \x74\x65\x20\x73\x6f\x54\x20\x6f
+ \x61\x4d\x79\x6e\x53\x20\x63\x65
+ \x65\x72\x73\x74\x54\x20\x6f\x6f
+ \x4d\x20\x6e\x61\x20\x79\x65\x53
+
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Mon, Jun 02, 2008 at 10:19:50PM +0200, Adrian-Ken Rueegsegger wrote:
Neil Horman wrote:
On Mon, Jun 02, 2008 at 10:48:48PM +1000, Herbert Xu wrote:
On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
Copy that. I think I found the problem, anyway. The verdict is that
Adrian was
right, and I'm klutz. I mixed up the output vector from a successful and
a
failed test during development. I'll repost shortly. Sorry for the
trouble!
No worries.
Ok, corrected the broken output vector and retested _several_ times. Also
added
to test case 4 as requested. Sorry again for the trouble
Thanks a lot for clearing this up! I don't know if this is appropriate but in
any case:
Thank you for your good eyes! They make an excellent backstop for sloppy
fingers :)
Acked-by: Adrian-Ken Rueegsegger [EMAIL PROTECTED]
Adrian
Patch to add checking of DES3 test vectors using CBC mode. FIPS-140-2
compliance mandates that any supported mode of operation must include a
self
test. This satisfies that requirement for cbc(des3_ede). The included
test
vector was generated by me using openssl. Key/IV was generated with the
following command:
openssl enc -des_ede_cbc -P
input and output values were generated by repeating the string Too many
secrets a few times over, truncating it to 128 bytes, and encrypting
it with
openssl using the aformentioned key. Tested successfully by myself
Signed-off-by: Neil Horman [EMAIL PROTECTED]
tcrypt.c | 16 ++
tcrypt.h | 93
---
2 files changed, 106 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6beabc5..30cd541 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1180,6 +1180,14 @@ static void do_test(void)
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
+
test_hash(md4, md4_tv_template, MD4_TEST_VECTORS);
test_hash(sha224, sha224_tv_template, SHA224_TEST_VECTORS);
@@ -1390,6 +1398,14 @@ static void do_test(void)
DES3_EDE_ENC_TEST_VECTORS);
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
break;
case 5:
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 47bc0ec..aaff76f 100644
--- a/crypto/tcrypt.h
+++ b/crypto/tcrypt.h
@@ -1442,6 +1442,8 @@ static struct hash_testvec hmac_sha512_tv_template[]
= {
#define DES_CBC_DEC_TEST_VECTORS 4
#define DES3_EDE_ENC_TEST_VECTORS 3
#define DES3_EDE_DEC_TEST_VECTORS 3
+#define DES3_EDE_CBC_ENC_TEST_VECTORS 1
+#define DES3_EDE_CBC_DEC_TEST_VECTORS 1
static struct cipher_testvec des_enc_tv_template[] = {
{ /* From Applied Cryptography */
@@ -1680,9 +1682,6 @@ static struct cipher_testvec
des_cbc_dec_tv_template[] = {
},
};
-/*
- * We really need some more test vectors, especially for DES3 CBC.
- */
static struct cipher_testvec des3_ede_enc_tv_template[] = {
{ /* These are from openssl */
.key= \x01\x23\x45\x67\x89\xab\xcd\xef
@@ -1745,6 +1744,94 @@ static struct cipher_testvec
des3_ede_dec_tv_template[] = {
},
};
+static struct cipher_testvec des3_ede_cbc_enc_tv_template[] = {
+ { /* Generated from openssl */
+ .key= \xE9\xC0\xFF\x2E\x76\x0B\x64\x24
+ \x44\x4D\x99\x5A\x12\xD6\x40\xC0
+ \xEA\xC2\x84\xE8\x14\x95\xDB\xE8,
+ .klen = 24,
+ .iv = \x7D\x33\x88\x93\x0F\x93\xB2\x42,
+ .input = \x6f\x54\x20\x6f\x61\x4d\x79\x6e
+ \x53\x20\x63\x65\x65\x72\x73\x74
+ \x54\x20\x6f\x6f\x4d\x20\x6e\x61
+ \x20\x79\x65\x53\x72\x63\x74\x65
+ \x20\x73\x6f\x54\x20\x6f\x61\x4d
+ \x79\x6e\x53\x20\x63\x65\x65\x72
+ \x73\x74\x54\x20\x6f\x6f\x4d\x20
+ \x6e\x61\x20\x79\x65\x53\x72\x63
+ \x74\x65\x20\x73\x6f\x54\x20\x6f
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
Adrian-Ken Rueegsegger wrote: Neil Horman wrote: On Sat, May 31, 2008 at 08:46:22AM +1000, Herbert Xu wrote: On Fri, May 30, 2008 at 07:26:38PM +0200, Adrian-Ken Rüegsegger wrote: I was wondering why you created your own test vectors. Wouldn't standardized test vectors by NIST or ANSI be preferable? If you could post a patch with those that would be very much appreciated. Thanks! I am putting together a patch using the test vectors found at [3] and the ones I gathered from ANSI X9.52 and ISO/IEC FDIS 10116:2005. Strange enough the ANSI and ISO test vectors pass while the ones from NIST do not yield the expected results. I have not yet identified the specific differences between the various test vector sets. It is not clearly stated if/which padding was employed so that might be the reason... The reason for getting different results with test vectors from [3] is, that one must repeatedly apply the encryption/decryption 1 times eventhough it's not clearly specified in that document itself. The Monte Carlo test that has to be used to get the results is described in [2] (section 3.2, page 24). Adrian For future reference, do you have a link where NIST standard test vectors can be obtained? A good place to start is [1]. More specifically for TDES: [2] and [3]. Note that the tests described in [2] will not work with the current DES3 implementation since the employed keys will be identified as weak keys and the setkey operation would fail. By the way: when explicitly trying to set a weak key for DES3 I got the following warning: setkey() failed flags=0 Shouldn't the flags be set to CRYPTO_TFM_RES_BAD_KEY_SCHED at that point (see crypto/des_generic.c, line 873)? Thanks, Adrian __ [1] - http://csrc.nist.gov/groups/STM/cavp/standards.html [2] - http://csrc.nist.gov/publications/nistpubs/800-20/800-20.pdf [3] - http://csrc.nist.gov/groups/STM/cavp/documents/des/tripledes-vectors.zip -- 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
