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

[christian.tschudin at unibas.ch]

On Wed, 27 May 2015, Thompson, Jeff wrote:

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

Hi Jeff,

This is a trick that Marc Mosko used when we presented the 1+0 encoding 
at the January ICNRG interim meeting: Just reduce then number of 
KeyID-Bits (2 Bytes, in our case), if need be.

The observation is that the key digest is for convenience, not security 
reasons: If you have many parties for which you have to maintain 
different symmetric keys, it is nice to quickly identify which key to 
use for validating the signature. But theoretically, you could just try 
out all symmetric keys you have for some peer. Rivest's "chaffing and 
winnowing" even relies on not sending any KeyID bits, on purpose.


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

First, it could be made optional. But then I think it would be good to 
write down how the digest is computed, as you suggest (because RFC 2104 
does not cover it, right?)

Adapted from previous text of yours:

"The Key must not be included in the signature but optionally a full or 
partial KeyDigest can be put in the KeyLocator block of the 
SignatureInfo field. If the byte length of Key is less than or equal to 
the SHA256 block length (64 bytes) then the full length 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 the 
full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest 
bits consist of 2 to 32 of the most-significant (=left-most) bytes of 
the full length KeyDigest. For the convenience of the validator and if 
packet size permits, it is recommended to include the full 32 bytes."

Would that be precise enough?

best, c

> 
> Thanks,
> - Jeff T
> 
> From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Wednesday, May 27, 2015 at 5:10
> To: Jeff Thompson <jefft0 at remap.ucla.edu>
> Cc: "ndn-interest at lists.cs.ucla.edu" <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> 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
> 
> 
>