>-----Original Message----- >From: Milan Broz [mailto:mbroz@xxxxxxxxxx] >Sent: Tuesday, November 20, 2012 10:04 PM >To: linux-crypto@xxxxxxxxxxxxxxx >Cc: Herbert Xu; Zhang, Sonic >Subject: Tcrypt hmac(crc32) test can work only on Blackfin > >Hi, > >commit a482b081a2d4d74d16bc9ea8779f9f6055f95852 >Author: Sonic Zhang <sonic.zhang@xxxxxxxxxx> >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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
