[Ndn-interest] Adding HMAC to available NDN signature types

Thompson, Jeff jefft0 at remap.UCLA.EDU
Mon Mar 9 06:07:26 PDT 2015


Hi Yingdi,

Following up to your message (6 months ago):

> Moreover, how to definition of KeyDigest is important in the validation part, so that data consumers can determine which symmetric key should be used to verify the HMAC. I agree with Marc that, for key longer than the block size, we can use the digest of digest of the key as the key id because the digest of the key is the actual key in this case.

Agreed for KeyDigest. The KeyLocator can also a key Name but normally a key Name is used to fetch a certificate which has more info. But there is not certificate for HMAC so would you agree that we only describe a KeyDigest for the KeyLocator?

Thanks,
- Jeff T

From: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>
Date: Tuesday, September 23, 2014 at 9:51
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: Adeola Bannis <abannis at ucla.edu<mailto:abannis at 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] Adding HMAC to available NDN signature types

Hi Jeff,

On Sep 22, 2014, at 10:02 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

Hash output length vs. block size…

Marc is right. The HmacWithSha256 algorithm hashes the key when it is longer than the block size (64 bytes), not the hash output length (32 bytes).  So we would prohibit keys longer than 64 bytes (not 32 bytes).

In Adeola's spec, the block size is not required to be 64 bytes. The RFC does not require the block size to be 64. I wonder if we should clarify that in the spec?

Also, most applications will use a crypto library's HMAC function which should automatically hash the key if it is longer than the block size. It could be confusing to put this in the spec since the application writer may unnecessarily has the key when the crypto library will do it anyway, and more efficiently.

I think the purpose of this spec is not only for application developers, but also for library developers, especially if we want to have good interoperability. So I think it would be better to clearly specify what is the requirement of generating a signature, how to generate a signature and what should be put into the SignatureInfo.

Moreover, how to definition of KeyDigest is important in the validation part, so that data consumers can determine which symmetric key should be used to verify the HMAC. I agree with Marc that, for key longer than the block size, we can use the digest of digest of the key as the key id because the digest of the key is the actual key in this case.

Yingdi

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


More information about the Ndn-interest mailing list