[Ndn-interest] Adding HMAC to available NDN signature types
jefft0 at remap.UCLA.EDU
Tue Sep 23 14:28:23 PDT 2014
> 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?
The RFC is is general for any hash algorithm, but Adeola's spec is specific to SHA-256. Since the spec is specific to SHA-256, I think we should show the exact values. In this case, the block size is 64 bytes.
- Jeff T
From: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>
Date: Tuesday, September 23, 2014 9:51 AM
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest