add self-tests for rfc4309(ccm(aes))
Subsystems (2)
PATCH 1/1 add self-tests for rfc4309(ccm(aes))
Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail.
--- crypto/tcrypt.c | 4 + crypto/testmgr.c | 15 +++ crypto/testmgr.h | 369 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 388 insertions(+), 0 deletions(-)
crypto/tcrypt.c +4 -0
@@ -667,6 +667,10 @@ static void do_test(int m)tcrypt_test ("zlib" );break ; +case 45 : +tcrypt_test ("rfc4309(ccm(aes))" ); +break ; +case 100 :tcrypt_test ("hmac(md5)" );break ;
crypto/testmgr.c +15 -0
@@ -1851,6 +1851,21 @@ static const struct alg_test_desc alg_test_descs[] = { } } }, { + .alg = "rfc4309(ccm(aes))", + .test = alg_test_aead, + .suite = { + .aead = { + .enc = { + .vecs = aes_ccm_rfc4309_enc_tv_template, + .count = AES_CCM_4309_ENC_TEST_VECTORS + }, + .dec = { + .vecs = aes_ccm_rfc4309_dec_tv_template, + .count = AES_CCM_4309_DEC_TEST_VECTORS + } + } + } + }, { .alg = "rmd128", .test = alg_test_hash, .suite = {
crypto/testmgr.h +369 -0
381 lines not on this page · raw message
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 10 lines · Jarod Wilson
Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail.
Signed-off-by Jarod Wilson <[email protected]><snip>
Quoted 9 lines
+/*
+ * rfc4309 says section 8 contains test vectors, only, it doesn't, and NIST
+ * Special Publication 800-38C's test vectors use nonce lengths our rfc4309
+ * implementation doesn't support. The following are taken from fips cavs
+ * fax files on hand at Red Hat.
+ *
+ * nb: actual key lengths are (klen - 3), the last 3 bytes are actually
+ * part of the nonce which combine w/the iv, but need to be input this way.
+ */
RFC4309 section 8 actually says the test vectors you can use are here:
http://www.ietf.org/rfc/rfc3610.txt
in RFC3610 section 8. I don't think theres anything wrong with the vectors your're using below, but you may want to add the vectors from 3610 just to imrpove the testing.
Other than that, looks good. Thanks for all the hard work!
Quoted 21 lines · On Thursday 09 April 2009 14:52:04 Neil Horman wrote:
Quoted 10 lines · Jarod Wilson
Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail.
Signed-off-by Jarod Wilson <[email protected]><snip>
Quoted 9 lines
+/*
+ * rfc4309 says section 8 contains test vectors, only, it doesn't, and NIST
+ * Special Publication 800-38C's test vectors use nonce lengths our rfc4309
+ * implementation doesn't support. The following are taken from fips cavs
+ * fax files on hand at Red Hat.
+ *
+ * nb: actual key lengths are (klen - 3), the last 3 bytes are actually
+ * part of the nonce which combine w/the iv, but need to be input this way.
+ */
Quoted 3 lines
RFC4309 section 8 actually says the test vectors you can use are here:
http://www.ietf.org/rfc/rfc3610.txt
in RFC3610 section 8.
Oh, I'm dense, didn't correctly parse that 4309 was referring back to 3610 for the actual test vectors. I'll see what I can do with those...
Quoted 3 lines
I don't think theres anything wrong with the vectors
your're using below, but you may want to add the vectors from 3610 just to imrpove the testing.
I think I'd drop some of the ones in the initial patch in favor of adding some from 3610, rather than simply adding more. The coverage is already pretty good, increasing the number of vectors shouldn't really be necessary, but it would definitely be nice to have vectors that are already publicly published and verified.
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 22 lines · Jarod Wilson
Quoted 21 lines · On Thursday 09 April 2009 14:52:04 Neil Horman wrote:
Quoted 19 lines · Jarod Wilson
Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail.
Signed-off-by Jarod Wilson <[email protected]><snip>
+/*
+ * rfc4309 says section 8 contains test vectors, only, it doesn't, and NIST
+ * Special Publication 800-38C's test vectors use nonce lengths our rfc4309
+ * implementation doesn't support. The following are taken from fips cavs
+ * fax files on hand at Red Hat.
+ *
+ * nb: actual key lengths are (klen - 3), the last 3 bytes are actually
+ * part of the nonce which combine w/the iv, but need to be input this way.
+ */
Quoted 7 lines
Quoted 3 lines
RFC4309 section 8 actually says the test vectors you can use are here:
http://www.ietf.org/rfc/rfc3610.txt
in RFC3610 section 8.Oh, I'm dense, didn't correctly parse that 4309 was referring back to 3610 for the actual test vectors. I'll see what I can do with those...
Its easy to miss. It referrs to the RFC in an endnote by reference.
Quoted 10 lines
Quoted 3 lines
I don't think theres anything wrong with the vectors
your're using below, but you may want to add the vectors from 3610 just to imrpove the testing.I think I'd drop some of the ones in the initial patch in favor of adding some from 3610, rather than simply adding more. The coverage is already pretty good, increasing the number of vectors shouldn't really be necessary, but it would definitely be nice to have vectors that are already publicly published and verified.
ACK to that.
Quoted 1 line
Quoted 9 lines · On Thursday 09 April 2009 22:31:08 Neil Horman wrote:
Quoted 8 lines · Jarod Wilson
Quoted 7 lines · On Thursday 09 April 2009 14:52:04 Neil Horman wrote:
Quoted 6 lines · Jarod Wilson
Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail.
Signed-off-by Jarod Wilson <[email protected]>
Ugh. I clearly missed *something* when testing, there's no way the patch I sent actually fully passed. I have things working for real now though locally, including a back-port to a certain 2.6.18-based kernel. :)
Updated patch or patches forthcoming... (probably tomorrow)
Signature · 2 lines
Jarod Wilson [email protected]
PATCH v2 1/1 crypto: add self-tests for rfc4309(ccm(aes))
One more time, with feeling. Investigated using test vectors from rfc3610, but they all use a 13-byte nonce, we only support 11-byte, so I'm sticking with using the samples from a fips cavs example file I have on hand.
I swear I tested the first version of the patch before submitting last time, but upon further testing, don't know how it actually managed to run correctly w/o some of the additional changes in this version.
This version contains the same vectors, but some of them had incorrect klen's in them last time. Additionally, null input and associated data should be handled more appropriately, as well as the expected decryption verification failure vectors.
This version of the patch has been tested on both 2.6.30-rc1-git5 + cryptodev-2.6 and a Red Hat Enterprise Linux 5.x kernel, with some extra debugging spew added to verify it really *is* working.
--- crypto/tcrypt.c | 4 + crypto/testmgr.c | 41 ++++++- crypto/testmgr.h | 371 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 414 insertions(+), 2 deletions(-)
crypto/tcrypt.c +4 -0
@@ -667,6 +667,10 @@ static void do_test(int m)tcrypt_test ("zlib" );break ; +case 45 : +tcrypt_test ("rfc4309(ccm(aes))" ); +break ; +case 100 :tcrypt_test ("hmac(md5)" );break ;
crypto/testmgr.c +39 -2
77 lines not on this page · raw message
crypto/testmgr.h +371 -0
389 lines not on this page · raw message
Signature · 2 lines
Jarod Wilson [email protected]
Re: [PATCH v2] crypto: add self-tests for rfc4309(ccm(aes))
Quoted 13 lines · Jarod Wilson
One more time, with feeling. Investigated using test vectors from rfc3610, but they all use a 13-byte nonce, we only support 11-byte, so I'm sticking with using the samples from a fips cavs example file I have on hand.
I swear I tested the first version of the patch before submitting last time, but upon further testing, don't know how it actually managed to run correctly w/o some of the additional changes in this version.
This version contains the same vectors, but some of them had incorrect klen's in them last time. Additionally, null input and associated data should be handled more appropriately, as well as the expected decryption verification failure vectors.
Quoted 6 lines
This version of the patch has been tested on both 2.6.30-rc1-git5 + cryptodev-2.6 and a Red Hat Enterprise Linux 5.x kernel, with some extra debugging spew added to verify it really *is* working.
Signed-off-by Jarod Wilson <[email protected]>
Quoted 1 line
Herbert Xu
maintainerRe: [PATCH v2] crypto: add self-tests for rfc4309(ccm(aes))
In reply to Jarod Wilsoncrypto/testmgr.c static int test_aead(struct crypto_aead *tfm, int enc, · line 389
Quoted 6 lines · Jarod Wilson
crypto/testmgr.c +4
-0+case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ + goto next_aead_vector;/* fall through */
We should also fail if novrfy is true and we get a 0 return value.
I'd also prefer to have the novrfy infrastructure changes to go into a separate patch.
Thanks,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH v2] crypto: add self-tests for rfc4309(ccm(aes))
Quoted 9 lines · On Wednesday 15 April 2009 07:20:53 Herbert Xu wrote:
crypto/testmgr.c static int test_aead(struct crypto_aead *tfm, int enc, · line 389
Quoted 6 lines · Jarod Wilson
crypto/testmgr.c +4
-0+case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ + goto next_aead_vector;/* fall through */ We should also fail if novrfy is true and we get a 0 return value.
Oh, yeah, whoops, missed that case. Will add that.
Quoted 2 lines
I'd also prefer to have the novrfy infrastructure changes to go into a separate patch.
Yeah, wasn't sure if I should do infra separate or not. I'll split things up a bit for the next submission that includes the catch for novrfy true, ret 0.
Signature · 2 lines
Jarod Wilson [email protected]
cover crypto: add testmgr support and self-tests for rfc4309
This patch series adds necessary fix-ups and infrastructure additions to testmgr/tcrypt to support the inclusion of rfc4309(ccm(aes)) self-tests, and finally, the rfc4309 test vectors themselves.
[PATCH 1/3] crypto: properly handle null input and assoc data aead test vectors [PATCH 2/3] crypto: handle ccm dec test vectors expected to fail verification [PATCH 3/3] crypto: add self-tests for rfc4309(ccm(aes))
Signature · 2 lines
Jarod Wilson [email protected]
PATCH 1/3 crypto: properly handle null input and assoc data aead test vectors
Currenty, if either input or associated data are null in an aead test vector, we'll have random contents of the input and assoc arrays. Similar to the iv, play it safe and zero out the contents.
--- crypto/testmgr.c | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-)
crypto/testmgr.c +12 -2
@@ -314,8 +314,18 @@ static int test_aead(struct crypto_aead *tfm, int enc, input = xbuf[0 ]; assoc = axbuf[0 ]; -memcpy (input, template[i].input, template[i].ilen); -memcpy (assoc, template[i].assoc, template[i].alen); +if (template[i].input) +memcpy (input, template[i].input, + template[i].ilen); +else +memset (input,0 ,MAX_IVLEN ); + +if (template[i].assoc) +memcpy (assoc, template[i].assoc, + template[i].alen); +else +memset (assoc,0 ,MAX_IVLEN ); +if (template[i].iv)memcpy (iv, template[i].iv,MAX_IVLEN );else
Signature · 6 lines
1.6.2.2 -- Jarod Wilson [email protected]
Herbert Xu
maintainerRe: [PATCH 1/3] crypto: properly handle null input and assoc data aead test vectors
Quoted 5 lines · Jarod Wilson
Currenty, if either input or associated data are null in an aead test vector, we'll have random contents of the input and assoc arrays. Similar to the iv, play it safe and zero out the contents.
Signed-off-by Jarod Wilson <[email protected]>
This patch doesn't make sense unless you were getting a crash without it.
Quoted 5 lines
crypto/testmgr.c +0
-0
crypto/testmgr.c static int test_aead(struct crypto_aead *tfm, int enc, · line 321
Quoted 10 lines
crypto/testmgr.c +5
-2@@ -314,8 +314,18 @@ static int test_aead(struct crypto_aead *tfm, int enc, input = xbuf[0 ]; assoc = axbuf[0 ]; -memcpy (input, template[i].input, template[i].ilen); -memcpy (assoc, template[i].assoc, template[i].alen); +if (template[i].input) +memcpy (input, template[i].input, + template[i].ilen); +else +memset (input,0 ,MAX_IVLEN );
If template[i].input was really NULL then the memcpy should crash.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH 1/3] crypto: properly handle null input and assoc data aead test vectors
Quoted 18 lines · Herbert Xu
Quoted 5 lines · Jarod Wilson
Currenty, if either input or associated data are null in an aead test vector, we'll have random contents of the input and assoc arrays. Similar to the iv, play it safe and zero out the contents.
Signed-off-by Jarod Wilson<[email protected]>This patch doesn't make sense unless you were getting a crash without it.
Quoted 8 lines
crypto/testmgr.c +0
-0@@ -314,8 +314,18 @@ static int test_aead(struct crypto_aead *tfm, int enc, input = xbuf[0 ]; assoc = axbuf[0 ];
Quoted 9 lines
crypto/testmgr.c static int test_aead(struct crypto_aead *tfm, int enc, · line 321
Quoted 7 lines
crypto/testmgr.c +5
-2-memcpy (input, template[i].input, template[i].ilen); -memcpy (assoc, template[i].assoc, template[i].alen); +if (template[i].input) +memcpy (input, template[i].input, + template[i].ilen); +else +memset (input,0 ,MAX_IVLEN );If template[i].input was really NULL then the memcpy should crash.
I needed to do this for some extended testing elsewhere in similar-looking code, where input could indeed be NULL and I did encounter crashes, but its not reproduceable within tcrypt/testmgr itself, so indeed, not necessary here.
Signature · 2 lines
Jarod Wilson [email protected]
PATCH 2/3 crypto: handle ccm dec test vectors expected to fail verification
In reply to Jarod WilsonAdd infrastructure to tcrypt to support handling ccm decryption test vectors that are expected to fail verification.
--- crypto/testmgr.c | 32 ++++++++++++++++++++++++++++++++ crypto/testmgr.h | 1 + 2 files changed, 33 insertions(+), 0 deletions(-)
crypto/testmgr.c +32 -0
@@ -373,6 +373,16 @@ static int test_aead(struct crypto_aead *tfm, int enc,switch (ret) {case 0 : +if (template[i].novrfy) { +/* verification was supposed to fail */ +printk (KERN_ERR "alg: aead: %s failed " +"on test %d for %s: ret was 0, " +"expected -EBADMSG\n" , + e, j, algo); +/* so really, we got a bad message */ + ret = -EBADMSG ; + goto out; + }break ;case -EINPROGRESS :case -EBUSY :
@@ -382,6 +392,10 @@ static int test_aead(struct crypto_aead *tfm, int enc,INIT_COMPLETION (result.completion);break ; } +case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ + goto next_aead_vector;/* fall through */ default : printk(KERN_ERR "alg: aead: %s failed on test "
@@ -398,6 +412,8 @@ static int test_aead(struct crypto_aead *tfm, int enc, goto out; } } +next_aead_vector: +continue ; }for (i =0 , j =0 ; i < tcount; i++) {
@@ -491,6 +507,16 @@ static int test_aead(struct crypto_aead *tfm, int enc,switch (ret) {case 0 : +if (template[i].novrfy) { +/* verification was supposed to fail */ +printk (KERN_ERR "alg: aead: %s failed " +"on chunk test %d for %s: ret " +"was 0, expected -EBADMSG\n" , + e, j, algo); +/* so really, we got a bad message */ + ret = -EBADMSG ; + goto out; + }break ;case -EINPROGRESS :case -EBUSY :
@@ -500,6 +526,10 @@ static int test_aead(struct crypto_aead *tfm, int enc,INIT_COMPLETION (result.completion);break ; } +case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ + goto next_aead_chunk_vector;/* fall through */ default : printk(KERN_ERR "alg: aead: %s failed on "
@@ -550,6 +580,8 @@ static int test_aead(struct crypto_aead *tfm, int enc, temp += template[i].tap[k]; } } +next_aead_chunk_vector: +continue ; } ret =0 ;
crypto/testmgr.h +1 -0
@@ -62,6 +62,7 @@ struct aead_testvec {int np;int anp;unsigned char fail; +unsigned char novrfy;/* ccm dec verification failure expected */ unsigned char wk;/* weak key flag */ unsigned char klen;unsigned short ilen;
Signature · 6 lines
1.6.2.2 -- Jarod Wilson [email protected]
Herbert Xu
maintainerRe: [PATCH 2/3] crypto: handle ccm dec test vectors expected to fail verification
Quoted 32 lines · Jarod Wilson
Add infrastructure to tcrypt to support handling ccm decryption test vectors that are expected to fail verification.
Signed-off-by Jarod Wilson <[email protected]>--- crypto/testmgr.c | 32 ++++++++++++++++++++++++++++++++ crypto/testmgr.h | 1 + 2 files changed, 33 insertions(+), 0 deletions(-)crypto/testmgr.c +10
-0@@ -373,6 +373,16 @@ static int test_aead(struct crypto_aead *tfm, int enc,switch (ret) {case 0 : +if (template[i].novrfy) { +/* verification was supposed to fail */ +printk (KERN_ERR "alg: aead: %s failed " +"on test %d for %s: ret was 0, " +"expected -EBADMSG\n" , + e, j, algo); +/* so really, we got a bad message */ + ret = -EBADMSG ; + goto out; + }break ;case -EINPROGRESS :case -EBUSY :
crypto/testmgr.c static int test_aead(struct crypto_aead *tfm, int enc, · line 399
Quoted 8 lines
crypto/testmgr.c +4
-0@@ -382,6 +392,10 @@ static int test_aead(struct crypto_aead *tfm, int enc,INIT_COMPLETION (result.completion);break ; } +case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ + goto next_aead_vector;/* fall through */
How about just doing continue instead of having this goto?
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH 2/3] crypto: handle ccm dec test vectors expected to fail verification
Quoted 35 lines · Herbert Xu
Quoted 34 lines · Jarod Wilson
Add infrastructure to tcrypt to support handling ccm decryption test vectors that are expected to fail verification.
Signed-off-by Jarod Wilson<[email protected]>--- crypto/testmgr.c | 32 ++++++++++++++++++++++++++++++++ crypto/testmgr.h | 1 + 2 files changed, 33 insertions(+), 0 deletions(-)crypto/testmgr.c +10
-0@@ -373,6 +373,16 @@ static int test_aead(struct crypto_aead *tfm, int enc,switch (ret) {case 0 : +if (template[i].novrfy) { +/* verification was supposed to fail */ +printk (KERN_ERR "alg: aead: %s failed " +"on test %d for %s: ret was 0, " +"expected -EBADMSG\n" , + e, j, algo); +/* so really, we got a bad message */ + ret = -EBADMSG ; + goto out; + }break ;case -EINPROGRESS :case -EBUSY :@@ -382,6 +392,10 @@ static int test_aead(struct crypto_aead *tfm, int enc,INIT_COMPLETION (result.completion);break ;
Quoted 8 lines
crypto/testmgr.c static int test_aead(struct crypto_aead *tfm, int enc, · line 399
Quoted 6 lines
crypto/testmgr.c +4
-0} +case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ + goto next_aead_vector;/* fall through */ How about just doing continue instead of having this goto?
Gah. Yeah, that makes sense. Relic of having some additional debug goo in there, where I wanted feedback from every loop of the test...
Signature · 2 lines
Jarod Wilson [email protected]
PATCH 3/3 crypto: add self-tests for rfc4309(ccm(aes))
In reply to Jarod WilsonAdd an array of encryption and decryption + verification self-tests for rfc4309(ccm(aes)).
Test vectors all come from sample FIPS CAVS files provided to Red Hat by a testing lab. Unfortunately, all the published sample vectors in RFC 3610 and NIST Special Publication 800-38C contain nonce lengths that the kernel's rfc4309 implementation doesn't support, so while using some public domain vectors would have been preferred, its not possible at this time.
--- crypto/tcrypt.c | 4 + crypto/testmgr.c | 15 +++ crypto/testmgr.h | 370 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 389 insertions(+), 0 deletions(-)
crypto/tcrypt.c +4 -0
@@ -667,6 +667,10 @@ static void do_test(int m)tcrypt_test ("zlib" );break ; +case 45 : +tcrypt_test ("rfc4309(ccm(aes))" ); +break ; +case 100 :tcrypt_test ("hmac(md5)" );break ;
crypto/testmgr.c +15 -0
@@ -1893,6 +1893,21 @@ static const struct alg_test_desc alg_test_descs[] = { } } }, { + .alg = "rfc4309(ccm(aes))", + .test = alg_test_aead, + .suite = { + .aead = { + .enc = { + .vecs = aes_ccm_rfc4309_enc_tv_template, + .count = AES_CCM_4309_ENC_TEST_VECTORS + }, + .dec = { + .vecs = aes_ccm_rfc4309_dec_tv_template, + .count = AES_CCM_4309_DEC_TEST_VECTORS + } + } + } + }, { .alg = "rmd128", .test = alg_test_hash, .suite = {
crypto/testmgr.h +370 -0
382 lines not on this page · raw message
Signature · 6 lines
1.6.2.2 -- Jarod Wilson [email protected]
Herbert Xu
maintainerRe: [PATCH 3/3] crypto: add self-tests for rfc4309(ccm(aes))
Quoted 11 lines · Jarod Wilson
Add an array of encryption and decryption + verification self-tests for rfc4309(ccm(aes)).
Test vectors all come from sample FIPS CAVS files provided to Red Hat by a testing lab. Unfortunately, all the published sample vectors in RFC 3610 and NIST Special Publication 800-38C contain nonce lengths that the kernel's rfc4309 implementation doesn't support, so while using some public domain vectors would have been preferred, its not possible at this time.
Signed-off-by Jarod Wilson <[email protected]>
This one looks good to me. So if you just drop patch 1 (unless there's something I'm missing), change patch 2 to use continue and resubmit, then I'll put them in cryptodev.
Thanks,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtv4 cover crypto: add testmgr support and self-tests for rfc4309
These patches add necessary infrastructure additions to testmgr/tcrypt to support the inclusion of rfc4309(ccm(aes)) self-tests, and the rfc4309 test vectors themselves.
[PATCH 1/2] crypto: handle ccm dec test vectors expected to fail verification [PATCH 2/2] crypto: add self-tests for rfc4309(ccm(aes))
Differences from prior submission:
- Patch 1 from the prior series dropped, as it turns out to be completely unnecessary.
- Now using continue directly when expected ccm dec verify failures are encountered, rather than wedging in an unneeded goto.
The self-tests patch itself remains unchanged.
Signature · 2 lines
Jarod Wilson [email protected]
PATCH 1/2 crypto: handle ccm dec test vectors expected to fail verification
Add infrastructure to tcrypt/testmgr to support handling ccm decryption test vectors that are expected to fail verification.
--- crypto/testmgr.c | 28 ++++++++++++++++++++++++++++ crypto/testmgr.h | 1 + 2 files changed, 29 insertions(+), 0 deletions(-)
crypto/testmgr.c +28 -0
@@ -363,6 +363,16 @@ static int test_aead(struct crypto_aead *tfm, int enc,switch (ret) {case 0 : +if (template[i].novrfy) { +/* verification was supposed to fail */ +printk (KERN_ERR "alg: aead: %s failed " +"on test %d for %s: ret was 0, " +"expected -EBADMSG\n" , + e, j, algo); +/* so really, we got a bad message */ + ret = -EBADMSG ; + goto out; + }break ;case -EINPROGRESS :case -EBUSY :
@@ -372,6 +382,10 @@ static int test_aead(struct crypto_aead *tfm, int enc,INIT_COMPLETION (result.completion);break ; } +case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ +continue ;/* fall through */ default : printk(KERN_ERR "alg: aead: %s failed on test "
@@ -481,6 +495,16 @@ static int test_aead(struct crypto_aead *tfm, int enc,switch (ret) {case 0 : +if (template[i].novrfy) { +/* verification was supposed to fail */ +printk (KERN_ERR "alg: aead: %s failed " +"on chunk test %d for %s: ret " +"was 0, expected -EBADMSG\n" , + e, j, algo); +/* so really, we got a bad message */ + ret = -EBADMSG ; + goto out; + }break ;case -EINPROGRESS :case -EBUSY :
@@ -490,6 +514,10 @@ static int test_aead(struct crypto_aead *tfm, int enc,INIT_COMPLETION (result.completion);break ; } +case -EBADMSG : +if (template[i].novrfy) +/* verification failure was expected */ +continue ;/* fall through */ default : printk(KERN_ERR "alg: aead: %s failed on "
crypto/testmgr.h +1 -0
@@ -62,6 +62,7 @@ struct aead_testvec {int np;int anp;unsigned char fail; +unsigned char novrfy;/* ccm dec verification failure expected */ unsigned char wk;/* weak key flag */ unsigned char klen;unsigned short ilen;
Signature · 2 lines
Jarod Wilson [email protected]
PATCH 2/2 crypto: add self-tests for rfc4309(ccm(aes))
In reply to Jarod WilsonAdd an array of encryption and decryption + verification self-tests for rfc4309(ccm(aes)).
Test vectors all come from sample FIPS CAVS files provided to Red Hat by a testing lab. Unfortunately, all the published sample vectors in RFC 3610 and NIST Special Publication 800-38C contain nonce lengths that the kernel's rfc4309 implementation doesn't support, so while using some public domain vectors would have been preferred, its not possible at this time.
--- crypto/tcrypt.c | 4 + crypto/testmgr.c | 15 +++ crypto/testmgr.h | 370 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 389 insertions(+), 0 deletions(-)
crypto/tcrypt.c +4 -0
@@ -667,6 +667,10 @@ static void do_test(int m)tcrypt_test ("zlib" );break ; +case 45 : +tcrypt_test ("rfc4309(ccm(aes))" ); +break ; +case 100 :tcrypt_test ("hmac(md5)" );break ;
crypto/testmgr.c +15 -0
@@ -1893,6 +1893,21 @@ static const struct alg_test_desc alg_test_descs[] = { } } }, { + .alg = "rfc4309(ccm(aes))", + .test = alg_test_aead, + .suite = { + .aead = { + .enc = { + .vecs = aes_ccm_rfc4309_enc_tv_template, + .count = AES_CCM_4309_ENC_TEST_VECTORS + }, + .dec = { + .vecs = aes_ccm_rfc4309_dec_tv_template, + .count = AES_CCM_4309_DEC_TEST_VECTORS + } + } + } + }, { .alg = "rmd128", .test = alg_test_hash, .suite = {
crypto/testmgr.h +370 -0
382 lines not on this page · raw message
Signature · 7 lines
1.6.2.2 -- Jarod Wilson [email protected]
Herbert Xu
maintainerRe: [PATCH v4 0/2] crypto: add testmgr support and self-tests for rfc4309
In reply to Jarod WilsonQuoted 6 lines · Jarod Wilson
These patches add necessary infrastructure additions to testmgr/tcrypt to support the inclusion of rfc4309(ccm(aes)) self-tests, and the rfc4309 test vectors themselves.
[PATCH 1/2] crypto: handle ccm dec test vectors expected to fail verification [PATCH 2/2] crypto: add self-tests for rfc4309(ccm(aes))
Both patches applied. Thanks a lot Jarod!
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt