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

Thompson, Jeff jefft0 at remap.UCLA.EDU
Wed Jun 10 14:32:50 PDT 2015

So, based of comments form Marc, Gene, Yingdi and others, it sounds like the spec should completely drop the description of KeyDigest based on the HMAC key. Any objections?

- Jeff T

From: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>
Date: Tuesday, June 9, 2015 at 13:44
To: Marc Mosko <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Cc: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>, "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?

Hi Marc,

I also do not think we should use digest of symmetric key. What I mean a "security property” here is a structured name of the symmetric key which allows one to determine the trust scope of the key. Neither digest nor first 4 byte of a digest can provide such information.


On Jun 9, 2015, at 1:05 PM, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:


I do not think using the sha256 digest of a symmetric key is a security property (in the good sense).  I think it is an unnecessary leaking of information.  Symmetric keys must be rotated, based on the rate at which they are used and based on time.  They are pair-wise associations.  So, one only needs to keep track of keys for the given partner, such as a namespace or endpoint.  And, one usually only needs to keep track of the last, current, and next keys to handle timing issues (or maybe just the current and next).  So, there should not be a giant library of keys.

Because the keys are rotated via a key exchange protocol they are easily identified by some index that can be cryptographically unrelated to the given key, preventing any possible information leakage.  It may or may not be a sequential number, it depends on the key exchange protocol.

Given that there are only a small number of keys that need to be maintained and that they are scoped by a namespace or endpoint, using the first 4-bytes of the key digest is highly likely to render uniqueness.  But, like I said, I don’t think using a key digest is the right thing to do with symmetric keys.

One needs a key exchange protocol because the next key should not be determined over a channel protected by the current key.  That would break forward secrecy.

Yes, if one has long-term statically configured keys one could identify them via their KeyDigest, but I think that is unwise.  Both because they are static and because you possibly leak information in the KeyDigest.

The issue of trust is separate from how a key is identified.  The trust must be established by knowing the identity of the key exchange protocol peer, which is likely an RSA or EC public key.  Trust decisions should never be made on the KeyDigest or KeyId until after one has verified the signature and then the remote identity is uniquely known based on which key verified the signature.  So, even if there were a collision in KeyDigest or KeyID, one could still have strong authentication based on which of the colliding keys actually verified.


On Jun 9, 2015, at 7:16 PM, Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>> wrote:

On Jun 9, 2015, at 8:29 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

> I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest?

Using a short identifier (4 bytes) is to keep the packet short for low-power devices. Making a short identifier from the digest is an easy way to get a unique identifier instead of maintaining a separate list of sequential ID numbers. Does that answer your question?

I do not think the first 4-bytes can provide a “unique” identifier. If uniqueness is the major concern, we should use digest, given collision in sha256 has not been found yet.

I did not quite understand what you mean by “a separate list of sequential ID numbers”.

My concern is about using digest or something related alone. Given HMAC is about authenticity, one might not be able to tell from a digest or even first 4 bytes that the key can be trusted for a particular data packet. We have to maintaining an additional mapping between the privilege of a key (which is usually the key name) and the key anyway. So using a digest does not save too much at the device side.

For length of the key locator, given the packet size is already 1500-byte, I am not sure if it is a good tradeoff to sacrifice some good security property for just tens of bytes.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150610/31639f70/attachment.html>

More information about the Ndn-interest mailing list