Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Sun, Jun 01, 2008 at 03:10:14AM +0200, Adrian-Ken Rueegsegger wrote:
Neil Horman wrote:
On Sat, May 24, 2008 at 10:06:25AM +1000, Herbert Xu wrote:
Could you document the source of these vectors in the patch
description please?
Sure, reposting
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
These tests both seem to fail on my machine. Did you verify that the tests
pass succesfully?
-Adrian
Yes, of course I did. I clearly indicated that I did in my commit message
above. I just verified on a separate system as well. You had mentioned that
some of the standard NIST vectors that you obtained were failing on your system
as well, is something perhaps misconfigured in your kernel build? Mind you I
can't imagine what that would be, and if it were just my vectors that were
failing for you I could imagine I missed something that would work in my testing
but fail in yours, but if standard vectors are failing it seems something else
might be wrong
Regards
Neil
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
tcrypt.c |8 +
tcrypt.h | 93
---
2 files changed, 98 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6beabc5..649a8e4 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);
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 47bc0ec..8893733 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
+ \x6f\x6f\x4d\x20\x6e\x61\x0a\x79,
+ .ilen = 128,
+ .result = \x15\x8d\x5d\x34\x1b\x3f\xda\xda
+ \x4f\xce\x21\x82\x12\x54\x21\x0d
+
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Sun, Jun 01, 2008 at 03:44:23AM +0200, 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... I thought that TDES input/output vectors had to be an even multiple of the key length. As such if the vectors aren't an even multiple, doesn't padding have to be employed? 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)? I ran into this too when I wrote my vector. I'm not sure why this is happening, as it appears the *flags-crt_flags | FLAGS statements should set these. I'm looking into why Neil 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
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
Neil Horman wrote: On Sun, Jun 01, 2008 at 03:44:23AM +0200, 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... I thought that TDES input/output vectors had to be an even multiple of the key length. As such if the vectors aren't an even multiple, doesn't padding have to be employed? It's actually multiple of the cipher's block length, which all plain-/ciphertext values of the test vectors are. I some cases keys are also padded if one only supplies 2 keys and not 3 (192 bits in total). Since I used the test vectors with three distinct 64 bit keys I was wrong with my thinking that padding could be an issue. As you mentioned in the other mail, I will see if something with my setup is off. 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)? I ran into this too when I wrote my vector. I'm not sure why this is happening, as it appears the *flags-crt_flags | FLAGS statements should set these. I'm looking into why Neil 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
[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
[RFC PATCH] [XFRM] xfrm_algo: correct usage of RIPEMD-160
This patch makes HMAC-RIPEMD-160 usable with IPsec/XFRM. 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. -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: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Sun, Jun 01, 2008 at 06:09:46PM +0200, Adrian-Ken Rueegsegger wrote:
Neil Horman wrote:
On Sun, Jun 01, 2008 at 03:10:14AM +0200, Adrian-Ken Rueegsegger wrote:
Neil Horman wrote:
On Sat, May 24, 2008 at 10:06:25AM +1000, Herbert Xu wrote:
Could you document the source of these vectors in the patch
description please?
Sure, reposting
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
These tests both seem to fail on my machine. Did you verify that the tests
pass succesfully?
-Adrian
Yes, of course I did. I clearly indicated that I did in my commit message
above. I just verified on a separate system as well. You had mentioned
that
some of the standard NIST vectors that you obtained were failing on your
system
as well, is something perhaps misconfigured in your kernel build? Mind you
I
can't imagine what that would be, and if it were just my vectors that were
failing for you I could imagine I missed something that would work in my
testing
but fail in yours, but if standard vectors are failing it seems something
else
might be wrong
Sorry, I did not mean to come off so hostile. I merely wanted to find out if
I was the only one with failing test results. I will investigate, why this
fails on my machine.
I know you didn't. I apologize as well. I can't imagine why they would be
failing. I verified them in the tcrypt self tests again, as well as under
openssl in userspace, and both passed correctly. I've still have no idea what
causes the failure. I do recall there being a case in the setkey path that
returned an error without setting flags. I hit that writing my vectors. I'll
see if I can find it again.
Neil
-Adrian
Regards
Neil
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
tcrypt.c |8 +
tcrypt.h | 93
---
2 files changed, 98 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6beabc5..649a8e4 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);
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 47bc0ec..8893733 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
+
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
Neil Horman wrote: On Sun, Jun 01, 2008 at 06:09:46PM +0200, Adrian-Ken Rueegsegger wrote: Neil Horman wrote: On Sun, Jun 01, 2008 at 03:10:14AM +0200, Adrian-Ken Rueegsegger wrote: Neil Horman wrote: [snip] These tests both seem to fail on my machine. Did you verify that the tests pass succesfully? -Adrian Yes, of course I did. I clearly indicated that I did in my commit message above. I just verified on a separate system as well. You had mentioned that some of the standard NIST vectors that you obtained were failing on your system as well, is something perhaps misconfigured in your kernel build? Mind you I can't imagine what that would be, and if it were just my vectors that were failing for you I could imagine I missed something that would work in my testing but fail in yours, but if standard vectors are failing it seems something else might be wrong Sorry, I did not mean to come off so hostile. I merely wanted to find out if I was the only one with failing test results. I will investigate, why this fails on my machine. I know you didn't. I apologize as well. I can't imagine why they would be failing. I verified them in the tcrypt self tests again, as well as under openssl in userspace, and both passed correctly. I've still have no idea what causes the failure. I do recall there being a case in the setkey path that returned an error without setting flags. I hit that writing my vectors. I'll see if I can find it again. 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? Here's a shot in the dark: was there a mixup during the patch submission? Maybe you submitted a different version of the patch than intended? 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: [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: Neil Horman wrote: On Sun, Jun 01, 2008 at 06:09:46PM +0200, Adrian-Ken Rueegsegger wrote: Neil Horman wrote: On Sun, Jun 01, 2008 at 03:10:14AM +0200, Adrian-Ken Rueegsegger wrote: Neil Horman wrote: [snip] These tests both seem to fail on my machine. Did you verify that the tests pass succesfully? -Adrian Yes, of course I did. I clearly indicated that I did in my commit message above. I just verified on a separate system as well. You had mentioned that some of the standard NIST vectors that you obtained were failing on your system as well, is something perhaps misconfigured in your kernel build? Mind you I can't imagine what that would be, and if it were just my vectors that were failing for you I could imagine I missed something that would work in my testing but fail in yours, but if standard vectors are failing it seems something else might be wrong Sorry, I did not mean to come off so hostile. I merely wanted to find out if I was the only one with failing test results. I will investigate, why this fails on my machine. I know you didn't. I apologize as well. I can't imagine why they would be failing. I verified them in the tcrypt self tests again, as well as under openssl in userspace, and both passed correctly. I've still have no idea what causes the failure. I do recall there being a case in the setkey path that returned an error without setting flags. I hit that writing my vectors. I'll see if I can find it again. 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? Here's a shot in the dark: was there a mixup during the patch submission? Maybe you submitted a different version of the patch than intended? Its possible. I've got some chores that I need to take care of right now, but I'll rebuild tomorrow with the patch from my post email and re-verify Neil 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 Sun, Jun 01, 2008 at 07:16:18PM +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]
Please submit this patch to [EMAIL PROTECTED] and cc
[EMAIL PROTECTED] 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
