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

[Marc.Mosko at parc.com]

One could always just double hash the key to get the keyid for hmac.

Personally, I would think that in general hmac keys need to be agreed on by a key exchange protocol so they are rotated periodically.  However that agreement protocol identifies keys could also be used as the keyid, such as a small integer.

Marc

On Sep 22, 2014, at 7:02 PM, Thompson, Jeff <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).
> 
> 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.
> 
> - Jeff T
> 
> From: <Thompson>, Jeff Thompson <jefft0 at remap.ucla.edu>
> Date: Monday, September 22, 2014 9:53 AM
> To: Yingdi Yu <yingdi at cs.ucla.edu>, Adeola Bannis <abannis at ucla.edu>
> Cc: "ndn-interest at lists.cs.ucla.edu" <Ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] Adding HMAC to available NDN signature types
> 
> On Fri, Sep 19, 2014 at 11:18 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:
> > However, when key is longer than the hash output, putting key digest into key locator directly expose the secret to other.
> 
> Oh crap, you're right!  Thanks for pointing that out.  I agree that we should prohibit KeyDigest in the case that the key is longer than 32 bytes.  I would reword the reason slightly: "When the key is longer than 32 bytes, the HmacWithSha256 algorithm uses the SHA-256 digest of the key, which would be the same as the KeyDigest, effectively exposing the secret."
> 
> - Jeff T
> 
> From: Yingdi Yu <yingdi at cs.ucla.edu>
> Date: Sunday, September 21, 2014 12:00 AM
> To: Adeola Bannis <abannis at ucla.edu>
> Cc: "ndn-interest at lists.cs.ucla.edu" <Ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] Adding HMAC to available NDN signature types
> 
> On Sep 20, 2014, at 11:18 AM, Adeola Bannis <abannis at ucla.edu> wrote:
> 
>> 
>> On Fri, Sep 19, 2014 at 11:18 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:
>>> 
>>> @Adeola, you probably want to forbid KeyDigest in KeyLocator for this HMAC signature. Because if key size is longer than hash output, the key digest is used instead. If we allow KeyDigest in KeyLocator, then some careless programmers may leak the secret.   
>> 
>> Well, a careless programmer could put a passphrase, or something used to derive the key, into a KeyLocator KeyName as well. We can go ahead and make the restriction, but there are other ways a programmer could shoot herself in the foot here.
> 
> I did not mean that "careless" as you describe. I mean those who do not know the details of HMAC.
> 
> The problem is that when key is shorter than hash output, it is safe to put key digest in the key locator. However, when key is longer than the hash output, putting key digest into key locator directly expose the secret to other, i.e., attackers can directly use the key digest to construct any legitimate HMAC. Therefore you either explicitly specify what should be used when KeyDigest is used as the KeyLocator, or you can disable the usage of KeyDigest in KeyLocator.
> 
> Yingdi 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140923/85626579/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140923/85626579/attachment.bin>