[Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?

[Thompson, Jeff]

The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed, and that we don't repeat the details of other algorithms like SHA-256.

Any opinions on removing the algorithm details?

- Jeff T
SignatureHmacWithSha256<cid:6B94E289-C6DC-4002-9EF9-948D08AD1503>

SignatureHmacWithSha256 defines a hash-based message authentication code that is calculated over the <cid:AC18F89D-17C3-42FC-9E01-3D98C498CF70> Name, <cid:FAADCD52-F5F2-4B4F-8F23-8572A094F60B> MetaInfo, <cid:63CEF72F-159E-490F-ACCD-10B291183891> Content, and <cid:4BC39041-4470-4AAE-A916-93EFAFB2F6C0> SignatureInfo TLVs, using SHA256 as the hashing function. The signature algorithm is defined in Section 2 in RFC 2104<http://tools.ietf.org/html/rfc2104#section-2>.

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 4
                    KeyLocator

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
                     BYTE++(=SHA256({KeyValue XOR opad, SHA256({KeyValue XOR ipad, Name, MetaInfo, Content, SignatureInfo})}))


where

opad = 0x5c5c5c...5c5c5c (repeated 64 times)
ipad = 0x363636...363636 (repeated 64 times)


Key is a shared key known to the sender and receiver of the signed packet. KeyValue is derived from a shared Key as follows. If the byte length of Key is less than the SHA256 block length (64 bytes) then append zeros to the end of the Key to create the 64-byte KeyValue. If the byte length of Key is greater than 64 bytes then hash it with SHA256 to produce a 32-byte value then append 32 zeros to the end to create the 64-byte KeyValue. (The HMAC functions in most cryptographic libraries are supplied the Key and will internally derive the KeyValue in this way.)

Note

Key is not included in the signature. It is the application’s responsibility to ensure that the receiver already knows the shared Key. It can be identified using a KeyDigest as the <cid:91E28A76-B2E3-4C4A-A5C6-B21BBE7AF358> KeyLocator block in the <cid:D9F93FE6-7AA5-4798-94A4-F9C08EEEF53D> SignatureInfo block of SignatureHmacWithSha256 as follows. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case KeyDigest is SHA256(SHA256(Key)).

Note

As stated in in Section 3 of RFC 2104<http://tools.ietf.org/html/rfc2104#section-3> , keys shorter than the SHA256 output byte length (32 bytes) are strongly discouraged.

Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties which holds the shared Key. The key is identified using a KeyDigest as described above. It is the application’s responsibility to establish the identities of the parties who hold the shared Key.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150518/7bbb2207/attachment.html>