[Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?
gts at ics.uci.EDU
Tue Jun 9 13:16:39 PDT 2015
FWIW, I fully agree with Marc's point of view, especially this bit:
> I think it is an unnecessary leaking of information.
On 6/9/15 10:05 PM, 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
> 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.
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest