[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
I figured this thread was a good chance to weigh in once again with the
suggestion that every ESP and AH draft include an example datagram that
nails down these pesky details about byte ordering, etc. That'll go a long
way to ensuring that a spec is unambiguously interpreted.
Below is a copy of a previous posting. Jim Hughes responded that the
upcoming draft of the combined DES-CBC-HMAC-replay draft would include such
an example.
mike
>Date: Fri, 20 Dec 1996 20:44:23
>To: hughes@nsco.network.com
>From: Michael Sabin <mike.sabin@worldnet.att.net>
>Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention
Security Transform to Proposed Standard
>Cc: iesg@ietf.org, ipsec@tis.com
>
>I went through the exercise of coding up an example datagram as per the
>draft. My goal was to chase down details about byte/bit orderings in and
>out of the DES, MD5, HMAC, and replay-count operations. I felt that
>most of the details were resolvable using the description in the draft
>and the cited references. However, in a few cases I felt I was
>guessing.
>
>One suggestion I have is that the draft include an example datagram,
>before and after encryption. This will unambiguously nail down all
>details about bit/byte ordering. Note that the individual specs for DES
>[FIPS-41], MD5 [RFC-1321], and HMAC [Krawczyk] include such examples.
>
>Below is the example I came up with. (If anybody is inclined to verify
>the example, I'd sure appreciate it. :-) ) Items marked with (*) are
>places where I felt I was guessing about byte/bit orderings; some
>clarification about these may be desirable.
>
>mike
>---------------------------------
>
>EXAMPLE
>
>Suppose the "master key" K from the key managment layer is:
>
> K =
> 01 23 45 67 89 ab cd ef 23 45 67 89 ab cd ef 01
> 45 67 89 ab cd ef 01 23 67 89 ab cd ef 01 23 45
> 89 ab cd ef 01 23 45 67 ab cd ef 01 23 45 67 89
> cd ef 01 23 45 67 89 ab ef 01 23 45 67 89 ab cd
>
>K consists of 512 octets. Octet 0 is 0x01, octet 1 is 0x23, octet 511
>is 0xcd.
>
>K is used to compute the following quantities:
>
> DES_Key_I = a4 34 41 46 f6 dc 8b 1d
> IV_Key_I = c8 44 86 79 51 a6 83 cc
> HMAC_Key_I = 98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6 dd 4f 1c 8d
> RP_Key_I = d3 1f e3 42
>
>Each of these quantities is a sequence of octets numbered 0, 1, 2, ...,
>with octet 0 listed first.
>
>Here is an example datagram prior to encryption, including the HMAC:
>
> 1f 2e 3d 4c // SPI
> d3 1f e3 42 // replay count
> 4e 6f 77 20 // payload
> 69 73 20 74 // payload
> 68 65 20 74 // payload
> 69 6d 65 20 // payload
> 66 6f 72 20 // payload
> 61 6c 6c 20 // payload
> f6 0f 02 06 // padding, pad length, payload type
> 8a 85 2a 16 // HMAC
> 2a 6a 0d de // HMAC
> 30 b1 e5 fa // HMAC
> a6 e1 fc c1 // HMAC
>
>(*) The initial value of the replay count, from RP_Key_I, is:
>
> initial replay count = 0xd31fe342 = 3,542,082,370
>
>(*) When computing the HMAC, the octets of the datagram are digested in
>network order: 0x1f, 0x2e, 0x3d, ..., 0x0f, 0x02, 0x06.
>
>The HMAC key, from HMAC_Key_I, is [98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6
>dd 4f 1c 8d]; 0x98 is octet 0, and 0x8d is octet 15.
>
>(*) The output of the HMAC calculation is inserted into the datagram in
>network order: 0x8a is octet 0, and 0xc1 is octet 15.
>
>
>Here is the datagram after encryption:
>
> 1f 2e 3d 4c // SPI
> ff 30 bf 0a // replay count
> 46 bd b7 94 // payload
> 33 ff 84 0e // payload
> d9 aa 76 7a // payload
> cb 20 da d8 // payload
> 87 8e bf 0f // payload
> 27 70 2c 99 // payload
> 2f e3 ce a2 // padding, pad length, payload type
> b1 cc 9a 6e // HMAC
> 34 b8 50 3a // HMAC
> 51 92 be 7f // HMAC
> e0 cb ba 05 // HMAC
>
>(*) The DES encryption key, prior to parity correction, is [a4 34 41
>46 f6 dc 8b 1d], from DES_Key_I.
>
>(*) The IV is [c8 44 86 79 51 a6 83 cc], from IV_Key_I.
>
>(*) The first input block to the DES-CBC encryption is [d3 1f e3 42 4e
>6f 77 20].
>