Neil Horman wrote: > On Sun, Jun 01, 2008 at 03:44:23AM +0200, Adrian-Ken Rueegsegger wrote: >> Neil Horman wrote: >>> On Sat, May 31, 2008 at 08:46:22AM +1000, Herbert Xu wrote: >>>> On Fri, May 30, 2008 at 07:26:38PM +0200, Adrian-Ken Rüegsegger wrote: >>>>> I was wondering why you created your own test vectors. Wouldn't standardized test vectors by NIST or ANSI be preferable? >>>> If you could post a patch with those that would be very much >>>> appreciated. Thanks! >> I am putting together a patch using the test vectors found at [3] and the ones I gathered from ANSI X9.52 and ISO/IEC FDIS 10116:2005. Strange enough the ANSI and ISO test vectors pass while the ones from NIST do not yield the expected results. I have not yet identified the specific differences between the various test vector sets. It is not clearly stated if/which padding was employed so that might be the reason... >> > > I thought that TDES input/output vectors had to be an even multiple of the key > length. As such if the vectors aren't an even multiple, doesn't padding have to > be employed? It's actually multiple of the cipher's block length, which all plain-/ciphertext values of the test vectors are. I some cases keys are also padded if one only supplies 2 keys and not 3 (192 bits in total). Since I used the test vectors with three distinct 64 bit keys I was wrong with my thinking that padding could be an issue. As you mentioned in the other mail, I will see if something with my setup is off. Adrian >>> For future reference, do you have a link where NIST standard test vectors can be >>> obtained? >> A good place to start is [1]. More specifically for TDES: [2] and [3]. Note that the tests described in [2] will not work with the current DES3 implementation since the employed keys will be identified as weak keys and the setkey operation would fail. >> >> By the way: when explicitly trying to set a weak key for DES3 I got the following warning: >> >> setkey() failed flags=0 >> >> Shouldn't the flags be set to CRYPTO_TFM_RES_BAD_KEY_SCHED at that point (see crypto/des_generic.c, line 873)? > I ran into this too when I wrote my vector. I'm not sure why this is happening, > as it appears the *flags->crt_flags | FLAGS statements should set these. I'm > looking into why > Neil > >> Thanks, >> Adrian >> __________ >> >> [1] - http://csrc.nist.gov/groups/STM/cavp/standards.html >> [2] - http://csrc.nist.gov/publications/nistpubs/800-20/800-20.pdf >> [3] - http://csrc.nist.gov/groups/STM/cavp/documents/des/tripledes-vectors.zip -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
