Per the NIST AESAVS document, Appendix A[1], it isn't possible to
have automated self-tests for counter-mode AES, but people are
misled to believe something is wrong by the message that says there
is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
messages if fips_enabled is set to avoid confusion.
Dependent on earlier patch 'crypto: catch base cipher self-test
failures in fips mode', which adds the test_done label.
[1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
Signed-off-by: Jarod Wilson <[email protected]>
---
crypto/testmgr.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 5a50416..39ffa69 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2134,6 +2134,17 @@ int alg_test(const char *driver, const char *alg, u32 type, u32 mask)
type, mask);
goto test_done;
notest:
+ /*
+ * Per NIST AESAVS[1], it isn't possible to have automated self-tests
+ * for counter mode aes vectors, they have to be covered by ecb mode
+ * and code inspection. The ecb mode tests are trigger above in the
+ * CRYPTO_ALG_TYPE_CIPHER section. Suppress warnings about missing
+ * ctr tests if we're in fips mode to avoid confusion.
+ *
+ * [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
+ */
+ if (fips_enabled && !strncmp(alg, "ctr(aes", 7))
+ goto test_done;
printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
test_done:
if (fips_enabled && rc)
--
Jarod Wilson
[email protected]
On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> have automated self-tests for counter-mode AES, but people are
> misled to believe something is wrong by the message that says there
> is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> messages if fips_enabled is set to avoid confusion.
>
> Dependent on earlier patch 'crypto: catch base cipher self-test
> failures in fips mode', which adds the test_done label.
>
> [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
>
> Signed-off-by: Jarod Wilson <[email protected]>
>
> ---
> crypto/testmgr.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 5a50416..39ffa69 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -2134,6 +2134,17 @@ int alg_test(const char *driver, const char *alg, u32 type, u32 mask)
> type, mask);
> goto test_done;
> notest:
> + /*
> + * Per NIST AESAVS[1], it isn't possible to have automated self-tests
> + * for counter mode aes vectors, they have to be covered by ecb mode
> + * and code inspection. The ecb mode tests are trigger above in the
> + * CRYPTO_ALG_TYPE_CIPHER section. Suppress warnings about missing
> + * ctr tests if we're in fips mode to avoid confusion.
> + *
> + * [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
> + */
> + if (fips_enabled && !strncmp(alg, "ctr(aes", 7))
> + goto test_done;
> printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
> test_done:
> if (fips_enabled && rc)
>
>From the way I read the document, anything operating in a counter mode will have
an unpredictable output (given the counter operation isn't specified). While
the above works, I'm not sure that it fully covers the various ccm modes
available (ccm_base and rfc4309). Perhaps instead it would be better to add a
TFM mask flag indicating that the selected transform included a unpredictable
component or counter input (marking the alg as being unsuitable for automatic
testing without knoweldge of the inner workings of that counter. Then you could
just test for that flag?
Neil
> --
> Jarod Wilson
> [email protected]
>
On Wednesday 29 April 2009 06:50:35 Neil Horman wrote:
> On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> > Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> > have automated self-tests for counter-mode AES, but people are
> > misled to believe something is wrong by the message that says there
> > is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> > messages if fips_enabled is set to avoid confusion.
> >
> > Dependent on earlier patch 'crypto: catch base cipher self-test
> > failures in fips mode', which adds the test_done label.
> >
> > [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
> >
> > Signed-off-by: Jarod Wilson <[email protected]>
> >
> > ---
> > crypto/testmgr.c | 11 +++++++++++
> > 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> > index 5a50416..39ffa69 100644
> > --- a/crypto/testmgr.c
> > +++ b/crypto/testmgr.c
> > @@ -2134,6 +2134,17 @@ int alg_test(const char *driver, const char *alg, u32 type, u32 mask)
> > type, mask);
> > goto test_done;
> > notest:
> > + /*
> > + * Per NIST AESAVS[1], it isn't possible to have automated self-tests
> > + * for counter mode aes vectors, they have to be covered by ecb mode
> > + * and code inspection. The ecb mode tests are trigger above in the
> > + * CRYPTO_ALG_TYPE_CIPHER section. Suppress warnings about missing
> > + * ctr tests if we're in fips mode to avoid confusion.
> > + *
> > + * [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
> > + */
> > + if (fips_enabled && !strncmp(alg, "ctr(aes", 7))
> > + goto test_done;
> > printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
> > test_done:
> > if (fips_enabled && rc)
> >
> From the way I read the document, anything operating in a counter mode will have
> an unpredictable output (given the counter operation isn't specified). While
> the above works, I'm not sure that it fully covers the various ccm modes
> available (ccm_base and rfc4309).
I believe Appendix A only applies for straight up counter-mode aes,
ccm_base and rfc4309 actually have well-defined counter operations.
We've already got self-tests for ccm(aes) and a pending patch for
rfc4309(ccm(aes), and since they don't start w/'ctr(aes', they
wouldn't be caught by that (admittedly hacky) check even if we
didn't have test vectors for them.
> Perhaps instead it would be better to add a
> TFM mask flag indicating that the selected transform included a unpredictable
> component or counter input (marking the alg as being unsuitable for automatic
> testing without knoweldge of the inner workings of that counter. Then you could
> just test for that flag?
Yeah, I thought about a flag too, but it seemed potentially a lot of
overhead for what might well be restricted to ctr(aes*). It might've
been relevant for ctr(des3_ede) or ctr(des), but they're not on the
fips approved algo/mode list, so I took the easy way out. I'm game to
go the flag route if need be though.
--
Jarod Wilson
[email protected]
On Wednesday 29 April 2009 08:46:47 Jarod Wilson wrote:
> On Wednesday 29 April 2009 06:50:35 Neil Horman wrote:
> > On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> > > Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> > > have automated self-tests for counter-mode AES, but people are
> > > misled to believe something is wrong by the message that says there
> > > is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> > > messages if fips_enabled is set to avoid confusion.
> > >
> > > Dependent on earlier patch 'crypto: catch base cipher self-test
> > > failures in fips mode', which adds the test_done label.
> > >
> > > [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
[...]
> > From the way I read the document, anything operating in a counter mode will have
> > an unpredictable output (given the counter operation isn't specified). While
> > the above works, I'm not sure that it fully covers the various ccm modes
> > available (ccm_base and rfc4309).
>
> I believe Appendix A only applies for straight up counter-mode aes,
> ccm_base and rfc4309 actually have well-defined counter operations.
> We've already got self-tests for ccm(aes) and a pending patch for
> rfc4309(ccm(aes), and since they don't start w/'ctr(aes', they
> wouldn't be caught by that (admittedly hacky) check even if we
> didn't have test vectors for them.
>
> > Perhaps instead it would be better to add a
> > TFM mask flag indicating that the selected transform included a unpredictable
> > component or counter input (marking the alg as being unsuitable for automatic
> > testing without knoweldge of the inner workings of that counter. Then you could
> > just test for that flag?
>
> Yeah, I thought about a flag too, but it seemed potentially a lot of
> overhead for what might well be restricted to ctr(aes*). It might've
> been relevant for ctr(des3_ede) or ctr(des), but they're not on the
> fips approved algo/mode list, so I took the easy way out. I'm game to
> go the flag route if need be though.
Neil and I talked a bit more off-list about the best approach to take, and
after a bit of trial and error, we came up with the idea to simply add an
'untestable' flag to the alg_test_desc struct, a corresponding entry for
ctr(aes) in alg_test_descs, and a hook to check for untestable algs in
alg_find_test().
Works well enough in local testing, eliminates the use of strncmp, and
results in far more granular control over marking which algs are
explicitly untestable and shouldn't have warnings printed for. At the
moment, I've gone for suppressing the warnings regardless of whether
we're in fips mode or not, but adding a different warning (er, info)
message in the untestable case works too, if that's preferred. The
errnos used seem appropriate, but I might have missed more appropriate
ones somewhere.
nb: this patch applies atop my earlier '[PATCH v2] crypto: catch base
cipher self-test failures in fips mode'.
Signed-off-by: Jarod Wilson <[email protected]>
---
crypto/testmgr.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f39c148..b78278c 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -94,6 +94,7 @@ struct alg_test_desc {
const char *alg;
int (*test)(const struct alg_test_desc *desc, const char *driver,
u32 type, u32 mask);
+ int untestable;
union {
struct aead_test_suite aead;
@@ -1518,6 +1519,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /*
+ * Automated ctr(aes) tests aren't possible per Appendix A of
+ * http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
+ */
+ .alg = "ctr(aes)",
+ .untestable = 1,
+ }, {
.alg = "cts(cbc(aes))",
.test = alg_test_skcipher,
.suite = {
@@ -2198,10 +2206,13 @@ static int alg_find_test(const char *alg)
continue;
}
+ if (alg_test_descs[i].untestable)
+ return -ENODATA;
+
return i;
}
- return -1;
+ return -ENOSYS;
}
int alg_test(const char *driver, const char *alg, u32 type, u32 mask)
@@ -2237,7 +2248,13 @@ test_done:
return rc;
notest:
- printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
+ switch (i) {
+ case -ENODATA:
+ break;
+ case -ENOSYS:
+ default:
+ printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
+ }
return 0;
}
EXPORT_SYMBOL_GPL(alg_test);
--
Jarod Wilson
[email protected]
On Thu, Apr 30, 2009 at 05:13:25PM -0400, Jarod Wilson wrote:
> On Wednesday 29 April 2009 08:46:47 Jarod Wilson wrote:
> > On Wednesday 29 April 2009 06:50:35 Neil Horman wrote:
> > > On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> > > > Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> > > > have automated self-tests for counter-mode AES, but people are
> > > > misled to believe something is wrong by the message that says there
> > > > is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> > > > messages if fips_enabled is set to avoid confusion.
> > > >
> > > > Dependent on earlier patch 'crypto: catch base cipher self-test
> > > > failures in fips mode', which adds the test_done label.
> > > >
> > > > [1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
> [...]
> > > From the way I read the document, anything operating in a counter mode will have
> > > an unpredictable output (given the counter operation isn't specified). While
> > > the above works, I'm not sure that it fully covers the various ccm modes
> > > available (ccm_base and rfc4309).
> >
> > I believe Appendix A only applies for straight up counter-mode aes,
> > ccm_base and rfc4309 actually have well-defined counter operations.
> > We've already got self-tests for ccm(aes) and a pending patch for
> > rfc4309(ccm(aes), and since they don't start w/'ctr(aes', they
> > wouldn't be caught by that (admittedly hacky) check even if we
> > didn't have test vectors for them.
> >
> > > Perhaps instead it would be better to add a
> > > TFM mask flag indicating that the selected transform included a unpredictable
> > > component or counter input (marking the alg as being unsuitable for automatic
> > > testing without knoweldge of the inner workings of that counter. Then you could
> > > just test for that flag?
> >
> > Yeah, I thought about a flag too, but it seemed potentially a lot of
> > overhead for what might well be restricted to ctr(aes*). It might've
> > been relevant for ctr(des3_ede) or ctr(des), but they're not on the
> > fips approved algo/mode list, so I took the easy way out. I'm game to
> > go the flag route if need be though.
>
> Neil and I talked a bit more off-list about the best approach to take, and
> after a bit of trial and error, we came up with the idea to simply add an
> 'untestable' flag to the alg_test_desc struct, a corresponding entry for
> ctr(aes) in alg_test_descs, and a hook to check for untestable algs in
> alg_find_test().
>
> Works well enough in local testing, eliminates the use of strncmp, and
> results in far more granular control over marking which algs are
> explicitly untestable and shouldn't have warnings printed for. At the
> moment, I've gone for suppressing the warnings regardless of whether
> we're in fips mode or not, but adding a different warning (er, info)
> message in the untestable case works too, if that's preferred. The
> errnos used seem appropriate, but I might have missed more appropriate
> ones somewhere.
>
> nb: this patch applies atop my earlier '[PATCH v2] crypto: catch base
> cipher self-test failures in fips mode'.
>
> Signed-off-by: Jarod Wilson <[email protected]>
>
> ---
> crypto/testmgr.c | 21 +++++++++++++++++++--
> 1 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index f39c148..b78278c 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -94,6 +94,7 @@ struct alg_test_desc {
> const char *alg;
> int (*test)(const struct alg_test_desc *desc, const char *driver,
> u32 type, u32 mask);
> + int untestable;
>
> union {
> struct aead_test_suite aead;
> @@ -1518,6 +1519,13 @@ static const struct alg_test_desc alg_test_descs[] = {
> }
> }
> }, {
> + /*
> + * Automated ctr(aes) tests aren't possible per Appendix A of
> + * http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf
> + */
> + .alg = "ctr(aes)",
> + .untestable = 1,
> + }, {
> .alg = "cts(cbc(aes))",
> .test = alg_test_skcipher,
> .suite = {
> @@ -2198,10 +2206,13 @@ static int alg_find_test(const char *alg)
> continue;
> }
>
> + if (alg_test_descs[i].untestable)
> + return -ENODATA;
> +
> return i;
> }
>
> - return -1;
> + return -ENOSYS;
> }
>
> int alg_test(const char *driver, const char *alg, u32 type, u32 mask)
> @@ -2237,7 +2248,13 @@ test_done:
> return rc;
>
> notest:
> - printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
> + switch (i) {
> + case -ENODATA:
> + break;
> + case -ENOSYS:
> + default:
> + printk(KERN_INFO "alg: No test for %s (%s)\n", alg, driver);
> + }
> return 0;
> }
> EXPORT_SYMBOL_GPL(alg_test);
>
>
> --
> Jarod Wilson
> [email protected]
>
Acked-by: Neil Horman <[email protected]>
On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> have automated self-tests for counter-mode AES, but people are
> misled to believe something is wrong by the message that says there
> is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> messages if fips_enabled is set to avoid confusion.
This is not true at all. In our implementation the counter is
set through the IV so it definitely is possible to test counter
mode algorithms in Linux.
Cheers,
--
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
On Monday 04 May 2009 07:10:10 Herbert Xu wrote:
> On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> > Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> > have automated self-tests for counter-mode AES, but people are
> > misled to believe something is wrong by the message that says there
> > is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> > messages if fips_enabled is set to avoid confusion.
>
> This is not true at all. In our implementation the counter is
> set through the IV so it definitely is possible to test counter
> mode algorithms in Linux.
Ah... Now I think I see... We can provide an initial counter w/o a
problem, but counter incrementation is implementation-specific, so
we can't have automated tests that cover multiple enc/dec ops, but
if we limit ourselves to just one op, self-tests should be perfectly
doable, and NIST SP 800-38A, Appendix F.5 has vectors we could make
use of (using just the block #1 values). At least, spot-checking
the vectors, I'm getting the expected results for the 1st block.
Okay, I'll whip something up in a sec.
--
Jarod Wilson
[email protected]
On Monday 04 May 2009 07:10:10 Herbert Xu wrote:
> On Tue, Apr 28, 2009 at 09:18:22PM -0400, Jarod Wilson wrote:
> > Per the NIST AESAVS document, Appendix A[1], it isn't possible to
> > have automated self-tests for counter-mode AES, but people are
> > misled to believe something is wrong by the message that says there
> > is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
> > messages if fips_enabled is set to avoid confusion.
>
> This is not true at all. In our implementation the counter is
> set through the IV so it definitely is possible to test counter
> mode algorithms in Linux.
Indeed, the first enc/dec operation after we set the counter *is*
completely deterministic across all implementations, the AESAVS
is referring to tests with multiple operations, which aren't
possible, due to varying implementations of counter increment
routines. This patch adds test vectors for ctr(aes), using the
first block input values from Appendix F.5 of NIST Special Pub
800-38A.
Was also necessary to rename the rfc3686(ctr(aes)) components
slightly, to resolve a namespace collision.
Signed-off-by: Jarod Wilson <[email protected]>
---
crypto/testmgr.c | 23 +++++++++++--
crypto/testmgr.h | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 109 insertions(+), 6 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ffe7963..0efdda7 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1518,6 +1518,21 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "ctr(aes)",
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = {
+ .enc = {
+ .vecs = aes_ctr_enc_tv_template,
+ .count = AES_CTR_ENC_TEST_VECTORS
+ },
+ .dec = {
+ .vecs = aes_ctr_dec_tv_template,
+ .count = AES_CTR_DEC_TEST_VECTORS
+ }
+ }
+ }
+ }, {
.alg = "cts(cbc(aes))",
.test = alg_test_skcipher,
.suite = {
@@ -1967,12 +1982,12 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.cipher = {
.enc = {
- .vecs = aes_ctr_enc_tv_template,
- .count = AES_CTR_ENC_TEST_VECTORS
+ .vecs = aes_ctr_rfc3686_enc_tv_template,
+ .count = AES_CTR_3686_ENC_TEST_VECTORS
},
.dec = {
- .vecs = aes_ctr_dec_tv_template,
- .count = AES_CTR_DEC_TEST_VECTORS
+ .vecs = aes_ctr_rfc3686_dec_tv_template,
+ .count = AES_CTR_3686_DEC_TEST_VECTORS
}
}
}
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index c1c709b..0a11285 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -2854,8 +2854,10 @@ static struct cipher_testvec cast6_dec_tv_template[] = {
#define AES_LRW_DEC_TEST_VECTORS 8
#define AES_XTS_ENC_TEST_VECTORS 4
#define AES_XTS_DEC_TEST_VECTORS 4
-#define AES_CTR_ENC_TEST_VECTORS 7
-#define AES_CTR_DEC_TEST_VECTORS 6
+#define AES_CTR_ENC_TEST_VECTORS 3
+#define AES_CTR_DEC_TEST_VECTORS 3
+#define AES_CTR_3686_ENC_TEST_VECTORS 7
+#define AES_CTR_3686_DEC_TEST_VECTORS 6
#define AES_GCM_ENC_TEST_VECTORS 9
#define AES_GCM_DEC_TEST_VECTORS 8
#define AES_CCM_ENC_TEST_VECTORS 7
@@ -3998,6 +4000,92 @@ static struct cipher_testvec aes_xts_dec_tv_template[] = {
static struct cipher_testvec aes_ctr_enc_tv_template[] = {
+ { /* From NIST Special Publication 800-38A, Appendix F.5 */
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6"
+ "\xab\xf7\x15\x88\x09\xcf\x4f\x3c",
+ .klen = 16,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a",
+ .ilen = 16,
+ .result = "\x87\x4d\x61\x91\xb6\x20\xe3\x26"
+ "\x1b\xef\x68\x64\x99\x0d\xb6\xce",
+ .rlen = 16,
+ }, {
+ .key = "\x8e\x73\xb0\xf7\xda\x0e\x64\x52"
+ "\xc8\x10\xf3\x2b\x80\x90\x79\xe5"
+ "\x62\xf8\xea\xd2\x52\x2c\x6b\x7b",
+ .klen = 24,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a",
+ .ilen = 16,
+ .result = "\x1a\xbc\x93\x24\x17\x52\x1c\xa2"
+ "\x4f\x2b\x04\x59\xfe\x7e\x6e\x0b",
+ .rlen = 16,
+ }, {
+ .key = "\x60\x3d\xeb\x10\x15\xca\x71\xbe"
+ "\x2b\x73\xae\xf0\x85\x7d\x77\x81"
+ "\x1f\x35\x2c\x07\x3b\x61\x08\xd7"
+ "\x2d\x98\x10\xa3\x09\x14\xdf\xf4",
+ .klen = 32,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a",
+ .ilen = 16,
+ .result = "\x60\x1e\xc3\x13\x77\x57\x89\xa5"
+ "\xb7\xa7\xf5\x04\xbb\xf3\xd2\x28",
+ .rlen = 16,
+ }
+};
+
+static struct cipher_testvec aes_ctr_dec_tv_template[] = {
+ { /* From NIST Special Publication 800-38A, Appendix F.5 */
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6"
+ "\xab\xf7\x15\x88\x09\xcf\x4f\x3c",
+ .klen = 16,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x87\x4d\x61\x91\xb6\x20\xe3\x26"
+ "\x1b\xef\x68\x64\x99\x0d\xb6\xce",
+ .ilen = 16,
+ .result = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a",
+ .rlen = 16,
+ }, {
+ .key = "\x8e\x73\xb0\xf7\xda\x0e\x64\x52"
+ "\xc8\x10\xf3\x2b\x80\x90\x79\xe5"
+ "\x62\xf8\xea\xd2\x52\x2c\x6b\x7b",
+ .klen = 24,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x1a\xbc\x93\x24\x17\x52\x1c\xa2"
+ "\x4f\x2b\x04\x59\xfe\x7e\x6e\x0b",
+ .ilen = 16,
+ .result = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a",
+ .rlen = 16,
+ }, {
+ .key = "\x60\x3d\xeb\x10\x15\xca\x71\xbe"
+ "\x2b\x73\xae\xf0\x85\x7d\x77\x81"
+ "\x1f\x35\x2c\x07\x3b\x61\x08\xd7"
+ "\x2d\x98\x10\xa3\x09\x14\xdf\xf4",
+ .klen = 32,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x60\x1e\xc3\x13\x77\x57\x89\xa5"
+ "\xb7\xa7\xf5\x04\xbb\xf3\xd2\x28",
+ .ilen = 16,
+ .result = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a",
+ .rlen = 16,
+ }
+};
+
+static struct cipher_testvec aes_ctr_rfc3686_enc_tv_template[] = {
{ /* From RFC 3686 */
.key = "\xae\x68\x52\xf8\x12\x10\x67\xcc"
"\x4b\xf7\xa5\x76\x55\x77\xf3\x9e"
--
Jarod Wilson
[email protected]
On Mon, May 04, 2009 at 02:56:58PM -0400, Jarod Wilson wrote:
>
> Ah... Now I think I see... We can provide an initial counter w/o a
> problem, but counter incrementation is implementation-specific, so
Not in Linux. If you're going to provide ctr you'd better increment
in the way the current implementation does it. Otherwise anything
that wraps around it, such as RFC3686 will fail.
Another way to put it, only the counter mode as used in RFC 3686,
CCM and GCM is what we call ctr.
Cheers,
--
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
On 05/04/2009 09:08 PM, Herbert Xu wrote:
> On Mon, May 04, 2009 at 02:56:58PM -0400, Jarod Wilson wrote:
>> Ah... Now I think I see... We can provide an initial counter w/o a
>> problem, but counter incrementation is implementation-specific, so
>
> Not in Linux. If you're going to provide ctr you'd better increment
> in the way the current implementation does it. Otherwise anything
> that wraps around it, such as RFC3686 will fail.
>
> Another way to put it, only the counter mode as used in RFC 3686,
> CCM and GCM is what we call ctr.
Yeah, no, I didn't mean within Linux we'd have different implementations,
I meant e.g. Linux vs. Windows vs. a Cisco router or what have you as far
as the base counter increment routine being implementation-specific.
Can't keep all the RFCs and SPs and whatnot straight in my head, and they
aren't in front of me, but I thought I read that the basic counter increment
routine wasn't mandated to be any specific way, the only mandate was to
ensure unique values. Suggestions for how to do so were made though.
That all seems to coincide with the AESAVS's assertion that automated
testing of ctr(aes) isn't possible, if one considers that Monte Carlo tests
are typically a standard part of all the other ciphers/modes full
validation test suites. I just initially read that to mean that self-tests
weren't possible, while I now believe its only referring to exhaustive
CAVS testing (i.e. w/MCT) not being possible, due to potential differences
from one counter inc routine to another.
Its also possible I'm losing my mind though.
--
Jarod Wilson
[email protected]
On Mon, May 04, 2009 at 11:45:08PM -0400, Jarod Wilson wrote:
>
> Can't keep all the RFCs and SPs and whatnot straight in my head, and they
> aren't in front of me, but I thought I read that the basic counter increment
> routine wasn't mandated to be any specific way, the only mandate was to
> ensure unique values. Suggestions for how to do so were made though.
It doesn't matter what is or isn't specified for CTR, the thing
that we call "ctr" is the one that's used for RFC 3686, CCM, and
GCM. It is completely pinned down and can be tested.
Cheers,
--
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
On Tuesday 05 May 2009 01:29:05 Herbert Xu wrote:
> On Mon, May 04, 2009 at 11:45:08PM -0400, Jarod Wilson wrote:
> >
> > Can't keep all the RFCs and SPs and whatnot straight in my head, and they
> > aren't in front of me, but I thought I read that the basic counter increment
> > routine wasn't mandated to be any specific way, the only mandate was to
> > ensure unique values. Suggestions for how to do so were made though.
>
> It doesn't matter what is or isn't specified for CTR, the thing
> that we call "ctr" is the one that's used for RFC 3686, CCM, and
> GCM. It is completely pinned down and can be tested.
There are two different "can be tested" contexts here. I completely
agree that ctr(aes) is testable within the tcrypt/testmgr context,
and sent a patch for such in this thread yesterday. The other
context is FIPS CAVS testing, which NIST is saying can't be done,
and I was attempting to understand why, which probably only served
to muddy the waters. We can definitely do self-tests for ctr(aes).
--
Jarod Wilson
[email protected]
On Mon, May 04, 2009 at 04:24:44PM -0400, Jarod Wilson wrote:
>
> Indeed, the first enc/dec operation after we set the counter *is*
> completely deterministic across all implementations, the AESAVS
> is referring to tests with multiple operations, which aren't
> possible, due to varying implementations of counter increment
> routines. This patch adds test vectors for ctr(aes), using the
> first block input values from Appendix F.5 of NIST Special Pub
> 800-38A.
Well, our ctr(aes) must be completely deterministic as it is
used as the base for CCM and GCM. In fact, if it weren't so
then you can't use it for anything since two implementations
may produces different outputs.
So if you could resend some vectors that test multiple blocks
then I'll happily add them.
Thanks,
--
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
On Tuesday 05 May 2009 09:18:35 Herbert Xu wrote:
> On Mon, May 04, 2009 at 04:24:44PM -0400, Jarod Wilson wrote:
> >
> > Indeed, the first enc/dec operation after we set the counter *is*
> > completely deterministic across all implementations, the AESAVS
> > is referring to tests with multiple operations, which aren't
> > possible, due to varying implementations of counter increment
> > routines. This patch adds test vectors for ctr(aes), using the
> > first block input values from Appendix F.5 of NIST Special Pub
> > 800-38A.
>
> Well, our ctr(aes) must be completely deterministic as it is
> used as the base for CCM and GCM. In fact, if it weren't so
> then you can't use it for anything since two implementations
> may produces different outputs.
Yeah, that makes sense, I believe I finally see the light.
> So if you could resend some vectors that test multiple blocks
> then I'll happily add them.
Multi-block test vectors coming shortly, passing in all the input
blocks from F.5 of 800-38A is spitting back the expected answers
for ever block.
--
Jarod Wilson
[email protected]
On Tuesday 05 May 2009 09:55:24 Jarod Wilson wrote:
> On Tuesday 05 May 2009 09:18:35 Herbert Xu wrote:
> > On Mon, May 04, 2009 at 04:24:44PM -0400, Jarod Wilson wrote:
> > >
> > > Indeed, the first enc/dec operation after we set the counter *is*
> > > completely deterministic across all implementations, the AESAVS
> > > is referring to tests with multiple operations, which aren't
> > > possible, due to varying implementations of counter increment
> > > routines. This patch adds test vectors for ctr(aes), using the
> > > first block input values from Appendix F.5 of NIST Special Pub
> > > 800-38A.
> >
> > Well, our ctr(aes) must be completely deterministic as it is
> > used as the base for CCM and GCM. In fact, if it weren't so
> > then you can't use it for anything since two implementations
> > may produces different outputs.
>
> Yeah, that makes sense, I believe I finally see the light.
>
> > So if you could resend some vectors that test multiple blocks
> > then I'll happily add them.
>
> Multi-block test vectors coming shortly, passing in all the input
> blocks from F.5 of 800-38A is spitting back the expected answers
> for ever block.
Now with multi-block test vectors, all from SP800-38A, Appendix F.5.
Also added ctr(aes) to case 10 in tcrypt.
Quickly smoke-tested in fips mode, got back "alg_test: alg
ctr(aes-x86_64) (ctr(aes)) self-test passed".
Signed-off-by: Jarod Wilson <[email protected]>
---
crypto/tcrypt.c | 1 +
crypto/testmgr.c | 23 ++++++-
crypto/testmgr.h | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 182 insertions(+), 6 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ea3b8a8..9e4974e 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -526,6 +526,7 @@ static void do_test(int m)
tcrypt_test("cbc(aes)");
tcrypt_test("lrw(aes)");
tcrypt_test("xts(aes)");
+ tcrypt_test("ctr(aes)");
tcrypt_test("rfc3686(ctr(aes))");
break;
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ffe7963..0efdda7 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1518,6 +1518,21 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "ctr(aes)",
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = {
+ .enc = {
+ .vecs = aes_ctr_enc_tv_template,
+ .count = AES_CTR_ENC_TEST_VECTORS
+ },
+ .dec = {
+ .vecs = aes_ctr_dec_tv_template,
+ .count = AES_CTR_DEC_TEST_VECTORS
+ }
+ }
+ }
+ }, {
.alg = "cts(cbc(aes))",
.test = alg_test_skcipher,
.suite = {
@@ -1967,12 +1982,12 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.cipher = {
.enc = {
- .vecs = aes_ctr_enc_tv_template,
- .count = AES_CTR_ENC_TEST_VECTORS
+ .vecs = aes_ctr_rfc3686_enc_tv_template,
+ .count = AES_CTR_3686_ENC_TEST_VECTORS
},
.dec = {
- .vecs = aes_ctr_dec_tv_template,
- .count = AES_CTR_DEC_TEST_VECTORS
+ .vecs = aes_ctr_rfc3686_dec_tv_template,
+ .count = AES_CTR_3686_DEC_TEST_VECTORS
}
}
}
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index c1c709b..6883fd7 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -2854,8 +2854,10 @@ static struct cipher_testvec cast6_dec_tv_template[] = {
#define AES_LRW_DEC_TEST_VECTORS 8
#define AES_XTS_ENC_TEST_VECTORS 4
#define AES_XTS_DEC_TEST_VECTORS 4
-#define AES_CTR_ENC_TEST_VECTORS 7
-#define AES_CTR_DEC_TEST_VECTORS 6
+#define AES_CTR_ENC_TEST_VECTORS 3
+#define AES_CTR_DEC_TEST_VECTORS 3
+#define AES_CTR_3686_ENC_TEST_VECTORS 7
+#define AES_CTR_3686_DEC_TEST_VECTORS 6
#define AES_GCM_ENC_TEST_VECTORS 9
#define AES_GCM_DEC_TEST_VECTORS 8
#define AES_CCM_ENC_TEST_VECTORS 7
@@ -3998,6 +4000,164 @@ static struct cipher_testvec aes_xts_dec_tv_template[] = {
static struct cipher_testvec aes_ctr_enc_tv_template[] = {
+ { /* From NIST Special Publication 800-38A, Appendix F.5 */
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6"
+ "\xab\xf7\x15\x88\x09\xcf\x4f\x3c",
+ .klen = 16,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a"
+ "\xae\x2d\x8a\x57\x1e\x03\xac\x9c"
+ "\x9e\xb7\x6f\xac\x45\xaf\x8e\x51"
+ "\x30\xc8\x1c\x46\xa3\x5c\xe4\x11"
+ "\xe5\xfb\xc1\x19\x1a\x0a\x52\xef"
+ "\xf6\x9f\x24\x45\xdf\x4f\x9b\x17"
+ "\xad\x2b\x41\x7b\xe6\x6c\x37\x10",
+ .ilen = 64,
+ .result = "\x87\x4d\x61\x91\xb6\x20\xe3\x26"
+ "\x1b\xef\x68\x64\x99\x0d\xb6\xce"
+ "\x98\x06\xf6\x6b\x79\x70\xfd\xff"
+ "\x86\x17\x18\x7b\xb9\xff\xfd\xff"
+ "\x5a\xe4\xdf\x3e\xdb\xd5\xd3\x5e"
+ "\x5b\x4f\x09\x02\x0d\xb0\x3e\xab"
+ "\x1e\x03\x1d\xda\x2f\xbe\x03\xd1"
+ "\x79\x21\x70\xa0\xf3\x00\x9c\xee",
+ .rlen = 64,
+ }, {
+ .key = "\x8e\x73\xb0\xf7\xda\x0e\x64\x52"
+ "\xc8\x10\xf3\x2b\x80\x90\x79\xe5"
+ "\x62\xf8\xea\xd2\x52\x2c\x6b\x7b",
+ .klen = 24,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a"
+ "\xae\x2d\x8a\x57\x1e\x03\xac\x9c"
+ "\x9e\xb7\x6f\xac\x45\xaf\x8e\x51"
+ "\x30\xc8\x1c\x46\xa3\x5c\xe4\x11"
+ "\xe5\xfb\xc1\x19\x1a\x0a\x52\xef"
+ "\xf6\x9f\x24\x45\xdf\x4f\x9b\x17"
+ "\xad\x2b\x41\x7b\xe6\x6c\x37\x10",
+ .ilen = 64,
+ .result = "\x1a\xbc\x93\x24\x17\x52\x1c\xa2"
+ "\x4f\x2b\x04\x59\xfe\x7e\x6e\x0b"
+ "\x09\x03\x39\xec\x0a\xa6\xfa\xef"
+ "\xd5\xcc\xc2\xc6\xf4\xce\x8e\x94"
+ "\x1e\x36\xb2\x6b\xd1\xeb\xc6\x70"
+ "\xd1\xbd\x1d\x66\x56\x20\xab\xf7"
+ "\x4f\x78\xa7\xf6\xd2\x98\x09\x58"
+ "\x5a\x97\xda\xec\x58\xc6\xb0\x50",
+ .rlen = 64,
+ }, {
+ .key = "\x60\x3d\xeb\x10\x15\xca\x71\xbe"
+ "\x2b\x73\xae\xf0\x85\x7d\x77\x81"
+ "\x1f\x35\x2c\x07\x3b\x61\x08\xd7"
+ "\x2d\x98\x10\xa3\x09\x14\xdf\xf4",
+ .klen = 32,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a"
+ "\xae\x2d\x8a\x57\x1e\x03\xac\x9c"
+ "\x9e\xb7\x6f\xac\x45\xaf\x8e\x51"
+ "\x30\xc8\x1c\x46\xa3\x5c\xe4\x11"
+ "\xe5\xfb\xc1\x19\x1a\x0a\x52\xef"
+ "\xf6\x9f\x24\x45\xdf\x4f\x9b\x17"
+ "\xad\x2b\x41\x7b\xe6\x6c\x37\x10",
+ .ilen = 64,
+ .result = "\x60\x1e\xc3\x13\x77\x57\x89\xa5"
+ "\xb7\xa7\xf5\x04\xbb\xf3\xd2\x28"
+ "\xf4\x43\xe3\xca\x4d\x62\xb5\x9a"
+ "\xca\x84\xe9\x90\xca\xca\xf5\xc5"
+ "\x2b\x09\x30\xda\xa2\x3d\xe9\x4c"
+ "\xe8\x70\x17\xba\x2d\x84\x98\x8d"
+ "\xdf\xc9\xc5\x8d\xb6\x7a\xad\xa6"
+ "\x13\xc2\xdd\x08\x45\x79\x41\xa6",
+ .rlen = 64,
+ }
+};
+
+static struct cipher_testvec aes_ctr_dec_tv_template[] = {
+ { /* From NIST Special Publication 800-38A, Appendix F.5 */
+ .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6"
+ "\xab\xf7\x15\x88\x09\xcf\x4f\x3c",
+ .klen = 16,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x87\x4d\x61\x91\xb6\x20\xe3\x26"
+ "\x1b\xef\x68\x64\x99\x0d\xb6\xce"
+ "\x98\x06\xf6\x6b\x79\x70\xfd\xff"
+ "\x86\x17\x18\x7b\xb9\xff\xfd\xff"
+ "\x5a\xe4\xdf\x3e\xdb\xd5\xd3\x5e"
+ "\x5b\x4f\x09\x02\x0d\xb0\x3e\xab"
+ "\x1e\x03\x1d\xda\x2f\xbe\x03\xd1"
+ "\x79\x21\x70\xa0\xf3\x00\x9c\xee",
+ .ilen = 64,
+ .result = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a"
+ "\xae\x2d\x8a\x57\x1e\x03\xac\x9c"
+ "\x9e\xb7\x6f\xac\x45\xaf\x8e\x51"
+ "\x30\xc8\x1c\x46\xa3\x5c\xe4\x11"
+ "\xe5\xfb\xc1\x19\x1a\x0a\x52\xef"
+ "\xf6\x9f\x24\x45\xdf\x4f\x9b\x17"
+ "\xad\x2b\x41\x7b\xe6\x6c\x37\x10",
+ .rlen = 64,
+ }, {
+ .key = "\x8e\x73\xb0\xf7\xda\x0e\x64\x52"
+ "\xc8\x10\xf3\x2b\x80\x90\x79\xe5"
+ "\x62\xf8\xea\xd2\x52\x2c\x6b\x7b",
+ .klen = 24,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x1a\xbc\x93\x24\x17\x52\x1c\xa2"
+ "\x4f\x2b\x04\x59\xfe\x7e\x6e\x0b"
+ "\x09\x03\x39\xec\x0a\xa6\xfa\xef"
+ "\xd5\xcc\xc2\xc6\xf4\xce\x8e\x94"
+ "\x1e\x36\xb2\x6b\xd1\xeb\xc6\x70"
+ "\xd1\xbd\x1d\x66\x56\x20\xab\xf7"
+ "\x4f\x78\xa7\xf6\xd2\x98\x09\x58"
+ "\x5a\x97\xda\xec\x58\xc6\xb0\x50",
+ .ilen = 64,
+ .result = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a"
+ "\xae\x2d\x8a\x57\x1e\x03\xac\x9c"
+ "\x9e\xb7\x6f\xac\x45\xaf\x8e\x51"
+ "\x30\xc8\x1c\x46\xa3\x5c\xe4\x11"
+ "\xe5\xfb\xc1\x19\x1a\x0a\x52\xef"
+ "\xf6\x9f\x24\x45\xdf\x4f\x9b\x17"
+ "\xad\x2b\x41\x7b\xe6\x6c\x37\x10",
+ .rlen = 64,
+ }, {
+ .key = "\x60\x3d\xeb\x10\x15\xca\x71\xbe"
+ "\x2b\x73\xae\xf0\x85\x7d\x77\x81"
+ "\x1f\x35\x2c\x07\x3b\x61\x08\xd7"
+ "\x2d\x98\x10\xa3\x09\x14\xdf\xf4",
+ .klen = 32,
+ .iv = "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7"
+ "\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff",
+ .input = "\x60\x1e\xc3\x13\x77\x57\x89\xa5"
+ "\xb7\xa7\xf5\x04\xbb\xf3\xd2\x28"
+ "\xf4\x43\xe3\xca\x4d\x62\xb5\x9a"
+ "\xca\x84\xe9\x90\xca\xca\xf5\xc5"
+ "\x2b\x09\x30\xda\xa2\x3d\xe9\x4c"
+ "\xe8\x70\x17\xba\x2d\x84\x98\x8d"
+ "\xdf\xc9\xc5\x8d\xb6\x7a\xad\xa6"
+ "\x13\xc2\xdd\x08\x45\x79\x41\xa6",
+ .ilen = 64,
+ .result = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96"
+ "\xe9\x3d\x7e\x11\x73\x93\x17\x2a"
+ "\xae\x2d\x8a\x57\x1e\x03\xac\x9c"
+ "\x9e\xb7\x6f\xac\x45\xaf\x8e\x51"
+ "\x30\xc8\x1c\x46\xa3\x5c\xe4\x11"
+ "\xe5\xfb\xc1\x19\x1a\x0a\x52\xef"
+ "\xf6\x9f\x24\x45\xdf\x4f\x9b\x17"
+ "\xad\x2b\x41\x7b\xe6\x6c\x37\x10",
+ .rlen = 64,
+ }
+};
+
+static struct cipher_testvec aes_ctr_rfc3686_enc_tv_template[] = {
{ /* From RFC 3686 */
.key = "\xae\x68\x52\xf8\x12\x10\x67\xcc"
"\x4b\xf7\xa5\x76\x55\x77\xf3\x9e"
--
Jarod Wilson
[email protected]
On Tue, May 05, 2009 at 10:42:58AM -0400, Jarod Wilson wrote:
>
> Now with multi-block test vectors, all from SP800-38A, Appendix F.5.
> Also added ctr(aes) to case 10 in tcrypt.
>
> Quickly smoke-tested in fips mode, got back "alg_test: alg
> ctr(aes-x86_64) (ctr(aes)) self-test passed".
>
> Signed-off-by: Jarod Wilson <[email protected]>
It didn't build because you forgot to change the RFC3686 dec
vector name. I've fixed it for you. Please test your patches
in future.
Thanks,
--
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
On Wednesday 06 May 2009 05:30:21 Herbert Xu wrote:
> On Tue, May 05, 2009 at 10:42:58AM -0400, Jarod Wilson wrote:
> >
> > Now with multi-block test vectors, all from SP800-38A, Appendix F.5.
> > Also added ctr(aes) to case 10 in tcrypt.
> >
> > Quickly smoke-tested in fips mode, got back "alg_test: alg
> > ctr(aes-x86_64) (ctr(aes)) self-test passed".
> >
> > Signed-off-by: Jarod Wilson <[email protected]>
>
> It didn't build because you forgot to change the RFC3686 dec
> vector name. I've fixed it for you. Please test your patches
> in future.
Gah, apologies. Tested it in that other kernel tree I needed to
get this done for, then neglected to do so for cryptodev.
Thanks for the fixage.
--
Jarod Wilson
[email protected]