Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-P1619] IEEE Security in Storage Working Group: P1619.1 CBC-AES-256-HMAC-SHA test vector 2

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 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
TAG 853c7403937d8b6239569b184eb7993fc5f751aefcea28f2c863858e2d29c50b
TAG 65e879d47df1def0af378d32e9f4fe3a824fb51e2143c03322def229361af3b1
TAG 7a724a3d653d05cb9f41f4b90d09e8e2886a78da48537d1cfa62977a82e7374e

Note 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.


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.


On Thu Mar 27 2014 at 10:11:25 AM, Michael Horst <m.horst@xxxxxxxxxxxx> wrote:

Hi Matt,


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 []
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


Hi Michael,


Please send your e-mail to 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 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:
TAG 256
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

TAG 512
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?

Thank you
Michael Horst


Matt Ball
Cell: 303-717-2717