|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Hi Michael,It looks like you've indeed found a mistake that has managed to live unnoticed for 7 years! I've dug through the e-mail archives to track down the origin of this mistake, and have found the following:If you look at http://grouper.ieee.org/groups/1619/email/doc00050.doc then this document has test vectors that match those that you computed (as produced by David McGrew).The e-mail here contains the TAG fields that match those of IEEE Std 1619.1-2007:Here's the test vector from that message:Test vector 2 KEY 0000000000000000000000000000000000000000000000000000000000000000 HMK 0000000000000000000000000000000000000000000000000000000000000000 HMK 0000000000000000000000000000000000000000000000000000000000000000 AAD 00000000000000000000000000000000 HMAC-SHA-256 TAG 853c7403937d8b6239569b184eb7993fc5f751aefcea28f2c863858e2d29c50b HMAC-SHA-512 TAG 65e879d47df1def0af378d32e9f4fe3a824fb51e2143c03322def229361af3b1 TAG 7a724a3d653d05cb9f41f4b90d09e8e2886a78da48537d1cfa62977a82e7374eNote that it does not contain a result for HMAC-SHA-1 and also omits the CIV field that is included in the standard.I suspect that I had transcribed David McGrew's inputs against Gideon's outputs and failed to notice the omission of the CIV field.Thanks for finding this! I'll investigate publishing this as an errata.Cheers,-Matt--On Sat, Mar 29, 2014 at 11:22 AM, Matt Ball <matt.ball@xxxxxxxx> wrote:
Please see below for a possible issue with P1619.1's CBC-AES-256-HMAC-SHA 256 and 512 test vector #2.Regards,-MattOn Thu Mar 27 2014 at 10:11:25 AM, Michael Horst <m.horst@xxxxxxxxxxxx> wrote:
can you forward this please.
I have just found out that the test vector 2 is inconsistent indeed. For SHA1, the TAG has been built over the given AAD and CIV, whereas for SHA-256 and SHA-256 over the AAD only. Note this vector does not contain any PTX/CTX.
I think the standard does not elaborate what to do if a plaintext record with 0 bytes needs to be stored. In our case this never will occur, as we use PKCS#7 padding.
The good news is that our implementation seems to be correct.
From: Matt Ball [mailto:firstname.lastname@example.org]
Sent: Donnerstag, 27. März 2014 15:31
To: Michael Horst
Subject: IEEE Security in Storage Working Group: P1619.1 CBC-AES-256-HMAC-SHA test vector 2
Please send your e-mail to STDS-P1619@xxxxxxxxxxxxx.org to ensure getting the best quality response. If you have issues joining this list, I'm am happy to forward this message on your behalf.
Note that we have double-checked all of these test vectors, so my first thought is that you have a mistake in your code. That said, it's always possible that we made a mistake, so it would be good if the wider group could take a look.
On Thu Mar 27 2014 at 2:33:12 AM, Michael Horst <m.horst@xxxxxxxxxxx> wrote:
This is an enquiry e-mail via http://siswg.net from:
Michael Horst <m.horst@xxxxxxxxxxx>
I am implementing CBC-AES-256-HMAC-SHA and test my code with the given test vectors. All test vectors produce the expected results except vector 2 for SHA-256 and SHA-512 while SHA-1 is ok. I wonder if there is an error in the test vector.
I get following results for the TAG:
33 ad 0a 1c 60 7e c0 3b 09 e6 cd 98 93 68 0c e2
10 ad f3 00 aa 1f 26 60 e1 b2 2e 10 f1 70 f9 2a
ba e4 6c eb eb bb 90 40 9a bc 5a cf 7a c2 1f db
33 9c 01 ce 15 19 2c 52 fb 9e 8a a1 1a 8d e9 a4
ea 15 a0 45 f2 be 24 5f bb 98 91 6a 9a e8 1b 35
3e 33 b9 c4 2a 55 38 0c 51 58 24 1d ae b3 c6 dd
Obviously, for this test vector, the TAG is the HMAC over 32 byte binary zeroes (AAD and CIV) with binary zeroes HMK.
Could you please have a look into this?