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

Adeola Bannis thecodemaiden at gmail.com
Fri Sep 19 16:58:21 PDT 2014

On Fri, Sep 19, 2014 at 4:19 PM, Junxiao Shi <shijunxiao at email.arizona.edu>

> Hi Adeola
> I agree with the necessity of HMAC signature.
> I have the following questions on the details:
>    - What's expected to appear in KeyLocator?
> In my current implementation, I am setting up communications between two
devices, and each of these devices is assigned an NDN name, which I can use
to identify the sender/receiver of a signed packet. I think this is an
implementation detail, similar to (partial) certificate names being used as
key names with the current RSA signature. That is, there is nothing forcing
someone implementing their own trust model with RSA signatures to use our
certificate Data type and certificate names.

To relate to the current RSA signature KeyLocator, you can think of it as
an identity instead of a full certificate name.

>    - What's the benefit of using opad and ipad?
>    - Why should SignatureValue contain two SHA256 hash functions? Why not
>    use just "SHA256(KeyValue, Name, MetaInfo, Content, SignatureInfo)"?
> This is how HMAC is defined (
http://www.ietf.org/rfc/rfc2104.txt). The two applications of SHA256 allow
the symmetric key to be embedded in the hash. Otherwise, it would be a
simple digest and could not prove the identity of a sender. The choice of
ipad and opad were made by someone more aware of hash function attacks than
I am.

> An accompanying document is needed to cover some guidance about how to
> design an application that makes use of HMAC signature and still guarantee
> a strong level of provenance.

There are many implementations of HMAC for authenticating web services. See
for an example. I am not sure that I would be able to provide better

> In particular, is this scheme usable if producer and sender do not exist
> at the same time?

I'm not sure what you mean by exist. If they both know the key, they can
exchange data. If you have old data stored and then someone tells you the
symmetric key used in signing, you can verify it. It is exactly the same as
if you encountered old data signed with an RSA private key, and then got
the corresponding public key by whatever means: you would then be able to
verify it.

> Yours, Junxiao​

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

More information about the Ndn-interest mailing list