[PATCH 4/6] crypto: testmgr - remove bfin_crc "hmac(crc32)" test vectors
From: Eric Biggers
The Blackfin CRC driver was removed by commit 9678a8dc53c1 ("crypto:
bfin_crc - remove blackfin CRC driver"), but it was forgotten to remove
the corresponding "hmac(crc32)" test vectors. I see no point in keeping
them since nothing else appears to implement or use "hmac(crc32)", which
isn't an algorithm that makes sense anyway because HMAC is meant to be
used with a cryptographically secure hash function, which CRC's are not.
Thus, remove the unneeded test vectors.
Signed-off-by: Eric Biggers
---
crypto/tcrypt.c | 4 ---
crypto/testmgr.c | 6
crypto/testmgr.h | 88
3 files changed, 98 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index e721faab6fc8..d5bcdd905007 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1942,10 +1942,6 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m, u32 num_mb)
ret += tcrypt_test("vmac(aes)");
break;
- case 110:
- ret += tcrypt_test("hmac(crc32)");
- break;
-
case 111:
ret += tcrypt_test("hmac(sha3-224)");
break;
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 41a5f42d4104..7e57530ecd52 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3168,12 +3168,6 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.hash = __VECS(ghash_tv_template)
}
- }, {
- .alg = "hmac(crc32)",
- .test = alg_test_hash,
- .suite = {
- .hash = __VECS(bfin_crc_tv_template)
- }
}, {
.alg = "hmac(md5)",
.test = alg_test_hash,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 552d8f00d85b..816e3eb197b2 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -43156,94 +43156,6 @@ static const struct hash_testvec crc32c_tv_template[]
= {
}
};
-/*
- * Blakcifn CRC test vectors
- */
-static const struct hash_testvec bfin_crc_tv_template[] = {
- {
- .psize = 0,
- .digest = "\x00\x00\x00\x00",
- },
- {
- .key = "\x87\xa9\xcb\xed",
- .ksize = 4,
- .psize = 0,
- .digest = "\x87\xa9\xcb\xed",
- },
- {
- .key = "\xff\xff\xff\xff",
- .ksize = 4,
- .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
-"\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
-"\x11\x12\x13\x14\x15\x16\x17\x18"
-"\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
-"\x21\x22\x23\x24\x25\x26\x27\x28",
- .psize = 40,
- .digest = "\x84\x0c\x8d\xa2",
- },
- {
- .key = "\xff\xff\xff\xff",
- .ksize = 4,
- .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
-"\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
-"\x11\x12\x13\x14\x15\x16\x17\x18"
-"\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
-"\x21\x22\x23\x24\x25\x26",
- .psize = 38,
- .digest = "\x8c\x58\xec\xb7",
- },
- {
- .key = "\xff\xff\xff\xff",
- .ksize = 4,
- .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
-"\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
-"\x11\x12\x13\x14\x15\x16\x17\x18"
-"\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
-"\x21\x22\x23\x24\x25\x26\x27",
- .psize = 39,
- .digest = "\xdc\x50\x28\x7b",
- },
- {
- .key = "\xff\xff\xff\xff",
- .ksize = 4,
- .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
-"\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
-"\x11\x12\x13\x14\x15\x16\x17\x18"
-"\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
-"\x21\x22\x23\x24\x25\x26\x27\x28"
-"\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30"
-"\x31\x32\x33\x34\x35\x36\x37\x38"
-"\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40"
-"\x41\x42\x43\x44\x45\x46\x47\x48"
-"\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50"
-
Re: hmac(crc32)
On Wed, Mar 08, 2017 at 09:20:08AM +0100, Stephan Müller wrote: > Hi Herbert, > > hmac(crc32) is defined in testmgr.c and tcrypt.c. Yet, when using that > cipher, > I get an ENOENT: > > alg: hash: Failed to load transform for hmac(crc32): -2 > > > Is there such a thing as hmac(crc32)? Yes this is a bogus driver implementation that sneaked through. We should remove bfin_crc along with the test vector. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
hmac(crc32)
Hi Herbert, hmac(crc32) is defined in testmgr.c and tcrypt.c. Yet, when using that cipher, I get an ENOENT: alg: hash: Failed to load transform for hmac(crc32): -2 Is there such a thing as hmac(crc32)? Ciao Stephan
Re: tcrypt failing on hmac(crc32)
Am Freitag, 27. Mai 2016, 11:19:32 schrieb Marcus Meissner: Hi Marcus, > > And it actually is: > > [ 180.942532] hmac: blocksize check failed, ds=4, cra_blocksize=1, ss=4 > [ 180.942541] alg: hash: Failed to load transform for hmac(crc32): -2 > [ 180.989191] tcrypt: one or more tests failed! > > Should I remove hmac(crc32) from the testmgr list? I am wondering about that: there are test vectors for this cipher, so there seem to be valid use cases. But the implementation is broken and nobody noticed up to now. So, it seems it is not in use? Given that, I would think that hmac(crc32) could be removed from testmgr. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcrypt failing on hmac(crc32)
On Wed, May 25, 2016 at 03:05:28PM +0200, Marcus Meissner wrote:
> On Wed, May 25, 2016 at 01:39:46PM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner:
> >
> > Hi Marcus,
> >
> > > Hi,
> > >
> > > On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote:
> > > > Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
> > > >
> > > > Hi Marcus,
> > > >
> > > > > Hi,
> > > > >
> > > > > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and
> > > > > running
> > > > > "modprobe tcrypt"
> > > > >
> > > > }, {
> > > >
> > > > .alg = "hmac(crc32)",
> > > > .test = alg_test_hash,
> > > >
> > > > ...
> > > >
> > > > fips_allowed = 1 missing?
> > >
> > > The kernel was not in FIPS mode, and adding it did not help. :/
> >
> > Sorry, I read FIPS and implied fips=1 :-)
>
> I think we are running in a precondition
>
> ds = salg->digestsize;// is CHKSUM_DIGEST_SIZE == 4
> for CRC32
> ss = salg->statesize; // ? cant find it
> alg = &salg->base;// base.cra_blocksize seems
> CHKSUM_BLOCKSIZE == 1
> if (ds > alg->cra_blocksize ||
> ss < alg->cra_blocksize)
> goto out_put_alg;
>
> 4 > 1 ... so EINVAL return.
>
> If this is the case, hmac(crc32) might be kind of non-sensical?
And it actually is:
[ 180.942532] hmac: blocksize check failed, ds=4, cra_blocksize=1, ss=4
[ 180.942541] alg: hash: Failed to load transform for hmac(crc32): -2
[ 180.989191] tcrypt: one or more tests failed!
Should I remove hmac(crc32) from the testmgr list?
Ciao, Marcus
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcrypt failing on hmac(crc32)
On Wed, May 25, 2016 at 01:39:46PM +0200, Stephan Mueller wrote:
> Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner:
>
> Hi Marcus,
>
> > Hi,
> >
> > On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote:
> > > Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
> > >
> > > Hi Marcus,
> > >
> > > > Hi,
> > > >
> > > > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> > > > "modprobe tcrypt"
> > > >
> > > }, {
> > >
> > > .alg = "hmac(crc32)",
> > > .test = alg_test_hash,
> > >
> > > ...
> > >
> > > fips_allowed = 1 missing?
> >
> > The kernel was not in FIPS mode, and adding it did not help. :/
>
> Sorry, I read FIPS and implied fips=1 :-)
I think we are running in a precondition
ds = salg->digestsize; // is CHKSUM_DIGEST_SIZE == 4 for CRC32
ss = salg->statesize; // ? cant find it
alg = &salg->base; // base.cra_blocksize seems
CHKSUM_BLOCKSIZE == 1
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;
4 > 1 ... so EINVAL return.
If this is the case, hmac(crc32) might be kind of non-sensical?
Ciao, Marcus
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcrypt failing on hmac(crc32)
Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner:
Hi Marcus,
> Hi,
>
> On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
> >
> > Hi Marcus,
> >
> > > Hi,
> > >
> > > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> > > "modprobe tcrypt"
> > >
> > }, {
> >
> > .alg = "hmac(crc32)",
> > .test = alg_test_hash,
> >
> > ...
> >
> > fips_allowed = 1 missing?
>
> The kernel was not in FIPS mode, and adding it did not help. :/
Sorry, I read FIPS and implied fips=1 :-)
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcrypt failing on hmac(crc32)
Hi,
On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote:
> Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
>
> Hi Marcus,
>
> > Hi,
> >
> > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> > "modprobe tcrypt"
>
> }, {
> .alg = "hmac(crc32)",
> .test = alg_test_hash,
> ...
>
> fips_allowed = 1 missing?
The kernel was not in FIPS mode, and adding it did not help. :/
Ciao, Marcus
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcrypt failing on hmac(crc32)
Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
Hi Marcus,
> Hi,
>
> when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> "modprobe tcrypt"
}, {
.alg = "hmac(crc32)",
.test = alg_test_hash,
...
fips_allowed = 1 missing?
>
> [ 1153.298266] alg: hash: Failed to load transform for hmac(crc32): -2
> [ 1153.340636] tcrypt: one or more tests failed!
>
> I spent some hours making sense of what is missing, but I got lost in the
> maze of the crypto apis between sync and async hashes somewhere.
>
> Does anyone know the solution for this, otherwise I will need to continue
> looking.
>
> Ciao, Marcus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tcrypt failing on hmac(crc32)
Hi, when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running "modprobe tcrypt" [ 1153.298266] alg: hash: Failed to load transform for hmac(crc32): -2 [ 1153.340636] tcrypt: one or more tests failed! I spent some hours making sense of what is missing, but I got lost in the maze of the crypto apis between sync and async hashes somewhere. Does anyone know the solution for this, otherwise I will need to continue looking. Ciao, Marcus -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Tcrypt hmac(crc32) test can work only on Blackfin
Hi Herbert, >-Original Message- >From: Herbert Xu [mailto:herb...@gondor.hengli.com.au] >Sent: Thursday, December 06, 2012 5:07 PM >To: Zhang, Sonic >Cc: Milan Broz; linux-crypto@vger.kernel.org >Subject: Re: Tcrypt hmac(crc32) test can work only on Blackfin > >On Thu, Nov 22, 2012 at 03:38:45AM -0500, Zhang, Sonic wrote: >> >> >On Wed, Nov 21, 2012 at 01:01:49PM +0100, Milan Broz wrote: >> >> >> >> On 11/21/2012 12:29 PM, Zhang, Sonic wrote: >> >> > Is there a policy that the CRC test vector in testmgr.h should >> >> > support all CRC drivers? >> >> > If so, I am fine to drop this test vector. >> >> >> >> Question for Herbert... >> >> But the problem I see is that it confuses people, it simply returns >> >> fail everytime (except Blackfin platform). >> >> >> >> My mail originates from bug report "tcrypt tests started failing", >> >> and it was not obvious why (for people not familiar with tcrypt >> >> internals, they just tried all test modes available). >> > >> >We should just make a generic version of crc32 available. >> > >> >> Hi Herbert and Broz, >> >> Unfortunately, after investigating the hardware manual of Blackfin CRC engine >and the CRC algorithm, I have to say the Blackfin CRC driver can't use current >crc32c test vector in testmgr.h. Blackfin CRC engine only supports big endian >CRC algorithm, while current crypto crc32c driver uses little endian CRC >algorithm. The big endian CRC digest is different from that of the little >endian. >> >> There are 2 solutions. One is to add a big endian crc32c test vector. The >> other >is to keep the Blackfin specific test vector. However, neither meets Broz's >expectation of a generic crc32 test vector. >> >> Any idea? > >I think we should just remove the blackfin crc driver altogether as nothing in >the >kernel ever uses hmac(crc32). > Blackfin Linux applications may use the crypto bfin_crc driver. I wish you could remove the blackfin crc test patch from testmgr, while keeping the driver as it is. Thanks, Sonic >Cheers, >-- >Email: Herbert Xu 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tcrypt hmac(crc32) test can work only on Blackfin
On Thu, Nov 22, 2012 at 03:38:45AM -0500, Zhang, Sonic wrote: > > >On Wed, Nov 21, 2012 at 01:01:49PM +0100, Milan Broz wrote: > >> > >> On 11/21/2012 12:29 PM, Zhang, Sonic wrote: > >> > Is there a policy that the CRC test vector in testmgr.h should > >> > support all CRC drivers? > >> > If so, I am fine to drop this test vector. > >> > >> Question for Herbert... > >> But the problem I see is that it confuses people, it simply returns > >> fail everytime (except Blackfin platform). > >> > >> My mail originates from bug report "tcrypt tests started failing", and > >> it was not obvious why (for people not familiar with tcrypt internals, > >> they just tried all test modes available). > > > >We should just make a generic version of crc32 available. > > > > Hi Herbert and Broz, > > Unfortunately, after investigating the hardware manual of Blackfin CRC engine > and the CRC algorithm, I have to say the Blackfin CRC driver can't use > current crc32c test vector in testmgr.h. Blackfin CRC engine only supports > big endian CRC algorithm, while current crypto crc32c driver uses little > endian CRC algorithm. The big endian CRC digest is different from that of the > little endian. > > There are 2 solutions. One is to add a big endian crc32c test vector. The > other is to keep the Blackfin specific test vector. However, neither meets > Broz's expectation of a generic crc32 test vector. > > Any idea? I think we should just remove the blackfin crc driver altogether as nothing in the kernel ever uses hmac(crc32). Cheers, -- Email: Herbert Xu 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tcrypt hmac(crc32) test can work only on Blackfin
On Wed, Nov 21, 2012 at 01:01:49PM +0100, Milan Broz wrote: > > On 11/21/2012 12:29 PM, Zhang, Sonic wrote: > > Is there a policy that the CRC test vector > > in testmgr.h should support all CRC drivers? > > If so, I am fine to drop this test vector. > > Question for Herbert... > But the problem I see is that it confuses people, it simply > returns fail everytime (except Blackfin platform). > > My mail originates from bug report "tcrypt tests started failing", > and it was not obvious why (for people not familiar with tcrypt > internals, they just tried all test modes available). We should just make a generic version of crc32 available. Thanks, -- Email: Herbert Xu 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Tcrypt hmac(crc32) test can work only on Blackfin
>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.hengli.com.au] >Sent: Thursday, November 22, 2012 10:33 AM >To: Milan Broz >Cc: Zhang, Sonic; linux-crypto@vger.kernel.org >Subject: Re: Tcrypt hmac(crc32) test can work only on Blackfin > >On Wed, Nov 21, 2012 at 01:01:49PM +0100, Milan Broz wrote: >> >> On 11/21/2012 12:29 PM, Zhang, Sonic wrote: >> > Is there a policy that the CRC test vector in testmgr.h should >> > support all CRC drivers? >> > If so, I am fine to drop this test vector. >> >> Question for Herbert... >> But the problem I see is that it confuses people, it simply returns >> fail everytime (except Blackfin platform). >> >> My mail originates from bug report "tcrypt tests started failing", and >> it was not obvious why (for people not familiar with tcrypt internals, >> they just tried all test modes available). > >We should just make a generic version of crc32 available. > Hi Herbert and Broz, Unfortunately, after investigating the hardware manual of Blackfin CRC engine and the CRC algorithm, I have to say the Blackfin CRC driver can't use current crc32c test vector in testmgr.h. Blackfin CRC engine only supports big endian CRC algorithm, while current crypto crc32c driver uses little endian CRC algorithm. The big endian CRC digest is different from that of the little endian. There are 2 solutions. One is to add a big endian crc32c test vector. The other is to keep the Blackfin specific test vector. However, neither meets Broz's expectation of a generic crc32 test vector. Any idea? Regard, Sonic -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tcrypt hmac(crc32) test can work only on Blackfin
On 11/21/2012 12:29 PM, Zhang, Sonic wrote: > Is there a policy that the CRC test vector > in testmgr.h should support all CRC drivers? > If so, I am fine to drop this test vector. Question for Herbert... But the problem I see is that it confuses people, it simply returns fail everytime (except Blackfin platform). My mail originates from bug report "tcrypt tests started failing", and it was not obvious why (for people not familiar with tcrypt internals, they just tried all test modes available). >> IMHO either it should provide crc32c (as do generic, sparc or x86 hw >> drivers) or >> the block size for crc32c should be 4... (and test vector is wrong then) >> > > I can set the default polynomials to that of crc32c for blackfin crc32 driver. > But, it should not be limited to crc32c. Sure, my question was just about test vector, hw driver support for something more is of course good thing. But it would be nice to have "crc32c" directly supported/accelerated as well. Thanks, Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Tcrypt hmac(crc32) test can work only on Blackfin
>-Original Message- >From: Milan Broz [mailto:mb...@redhat.com] >Sent: Tuesday, November 20, 2012 10:04 PM >To: linux-crypto@vger.kernel.org >Cc: Herbert Xu; Zhang, Sonic >Subject: Tcrypt hmac(crc32) test can work only on Blackfin > >Hi, > >commit a482b081a2d4d74d16bc9ea8779f9f6055f95852 >Author: Sonic Zhang >Date: Fri May 25 17:54:13 2012 +0800 >crypto: testmgr - Add new test cases for Blackfin CRC crypto driver > >added tcrypt mode=110 test for hmac(crc32) > >It seems, that this mode is only directly implemented by Blackfin driver and >must >fail on all other architectures because: > >- nobody implements "crc32" but "crc32c" > >- the block size is 1 and digest size is 4 for crc32[c], so >hmac(crc32c) must fail because ds > block_size (test in hmac_create) > >And it doesn't fail here because you implement it directly and not using >hmac.c... > >Just try modprobe tcrypt mode=110 on so other arch > alg: hash: Failed to load transform for hmac(crc32): -2 > >Why was such one-device dependent test vector added? > Blackfin CRC engine is flexible to support many CRC32 polynomials (include crc32c) and is able to append 0 to any block size which is not a multiple of 4. This Blackfin CRC engine specific test vector show these capabilities. Is there a policy that the CRC test vector in testmgr.h should support all CRC drivers? If so, I am fine to drop this test vector. >IMHO either it should provide crc32c (as do generic, sparc or x86 hw drivers) >or >the block size for crc32c should be 4... (and test vector is wrong then) > I can set the default polynomials to that of crc32c for blackfin crc32 driver. But, it should not be limited to crc32c. Regards, Sonic >But now we have test vector which must fail for most of systems. > >Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tcrypt hmac(crc32) test can work only on Blackfin
Hi, commit a482b081a2d4d74d16bc9ea8779f9f6055f95852 Author: Sonic Zhang Date: Fri May 25 17:54:13 2012 +0800 crypto: testmgr - Add new test cases for Blackfin CRC crypto driver added tcrypt mode=110 test for hmac(crc32) It seems, that this mode is only directly implemented by Blackfin driver and must fail on all other architectures because: - nobody implements "crc32" but "crc32c" - the block size is 1 and digest size is 4 for crc32[c], so hmac(crc32c) must fail because ds > block_size (test in hmac_create) And it doesn't fail here because you implement it directly and not using hmac.c... Just try modprobe tcrypt mode=110 on so other arch alg: hash: Failed to load transform for hmac(crc32): -2 Why was such one-device dependent test vector added? IMHO either it should provide crc32c (as do generic, sparc or x86 hw drivers) or the block size for crc32c should be 4... (and test vector is wrong then) But now we have test vector which must fail for most of systems. Milan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
