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

[GTS]

FWIW, I fully agree with Marc's point of view, especially this bit:
> I think it is an unnecessary leaking of information. 

Cheers,
Gene




On 6/9/15 10:05 PM, Marc.Mosko at parc.com wrote:
> Yingdi,
>
> 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.
>
> Marc
>
> 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.
>>
>> 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/20150609/93df94e1/attachment.html>