<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 5:46 PM, Tai-Lin Chu <span dir="ltr"><<a href="mailto:tailinchu@gmail.com" target="_blank">tailinchu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1. just to make sure: you are proposing "standard" sha256 hmac.<br>
<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. The biggest benefit that I can see from hmac is that it is faster<br>
to both encode/decode. As a result, we can use RSA to first bootstrap<br>
a symmetric key and use it for hmac.<br>
<div><div class="h5"><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
On Fri, Sep 19, 2014 at 4:58 PM, Adeola Bannis <<a href="mailto:thecodemaiden@gmail.com">thecodemaiden@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Sep 19, 2014 at 4:19 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
> wrote:<br>
>><br>
>> Hi Adeola<br>
>><br>
>> I agree with the necessity of HMAC signature.<br>
>><br>
>> I have the following questions on the details:<br>
>><br>
>> What's expected to appear in KeyLocator?<br>
><br>
> In my current implementation, I am setting up communications between two<br>
> devices, and each of these devices is assigned an NDN name, which I can use<br>
> to identify the sender/receiver of a signed packet. I think this is an<br>
> implementation detail, similar to (partial) certificate names being used as<br>
> key names with the current RSA signature. That is, there is nothing forcing<br>
> someone implementing their own trust model with RSA signatures to use our<br>
> certificate Data type and certificate names.<br>
><br>
> To relate to the current RSA signature KeyLocator, you can think of it as an<br>
> identity instead of a full certificate name.<br>
><br>
>><br>
>> What's the benefit of using opad and ipad?<br>
>> Why should SignatureValue contain two SHA256 hash functions? Why not use<br>
>> just "SHA256(KeyValue, Name, MetaInfo, Content, SignatureInfo)"?<br>
><br>
> This is how HMAC is defined<br>
> (<a href="http://en.wikipedia.org/wiki/Hash-based_message_authentication_code" target="_blank">http://en.wikipedia.org/wiki/Hash-based_message_authentication_code</a><br>
> <a href="http://www.ietf.org/rfc/rfc2104.txt" target="_blank">http://www.ietf.org/rfc/rfc2104.txt</a>). The two applications of SHA256 allow<br>
> the symmetric key to be embedded in the hash. Otherwise, it would be a<br>
> simple digest and could not prove the identity of a sender. The choice of<br>
> ipad and opad were made by someone more aware of hash function attacks than<br>
> I am.<br>
><br>
>><br>
>><br>
>> An accompanying document is needed to cover some guidance about how to<br>
>> design an application that makes use of HMAC signature and still guarantee a<br>
>> strong level of provenance.<br>
><br>
><br>
> There are many implementations of HMAC for authenticating web services. See<br>
> <a href="http://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/HMACAuth.html" target="_blank">http://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/HMACAuth.html</a><br>
> for an example. I am not sure that I would be able to provide better<br>
> guidance.<br>
><br>
><br>
>><br>
>> In particular, is this scheme usable if producer and sender do not exist<br>
>> at the same time?<br>
><br>
><br>
> I'm not sure what you mean by exist. If they both know the key, they can<br>
> exchange data. If you have old data stored and then someone tells you the<br>
> symmetric key used in signing, you can verify it. It is exactly the same as<br>
> if you encountered old data signed with an RSA private key, and then got the<br>
> corresponding public key by whatever means: you would then be able to verify<br>
> it.<br>
><br>
>><br>
>> Yours, Junxiao<br>
><br>
><br>
> Thanks,<br>
> Adeola<br>
><br>
</div></div>> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
><br>
_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</blockquote></div><br></div></div>