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

[Thompson, Jeff]

Hello Christian,

Two questions:

1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes?

2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec?

Thanks,
- Jeff T

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wednesday, May 27, 2015 at 5:10
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?

Dear folks

Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format spec.
Instead, the implementer should be referred to RFC.

Those details are duplication of RFC, and they would make the spec unnecessary long.
They also increase the probability of incorrect implementations because the implementer is unsure whether it's exactly same as what she/he has in the library, and would have to implement it again.
"don't have HMAC in their crypto library" is not a valid argument - it's easier to find an RFC-compliant library or snippet for most languages than to implement according to the (duplicate of RFC in) spec.

Yours, Junxiao

On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150527/a5155b8d/attachment.html>