[Ndn-interest] Interest Signature

Mon Jan 14 13:19:05 PST 2019

>>> Actually not. The reason why we don't include Name's T and L is because after generating the signature value, we need to append a SignedInterestSha256Digest component to the end of the current name, thus changing the Name's L.
This cuase extra overhead when verifying the signature -- receiver needs to calculate and modify the L before signature verification.

Might I suggest that you pre-append a zero-ed component and adjust the L, then do the signature.  The receiver would then need to zero the field to compare signatures.  That would allow keeping the Name T & L so the digest is over properly delimited fields.  Otherwise, I would try to find some other way of delimiting the name value to avoid attacks on the multiple fields.  One example would be to just include a length in the digest before the Name of the name length you're digesting.  It could just be a simple uint32 and does not need to be fancy.

I was not clear on why the SignedInterestSha256Digest included the InterestSignatureValue -- that is to make the name uniquely correlated to the signer?  It is not clear to me what security value this adds compared to having SignedInterestSha256Digest = Digest(Parameters, SignedInfo).  This is because you're already binding SignedInterestSha256Digest to the KeyId and using the KeyId to verify the signature over a larger body.  If it is possible to remove InterestSignatureValue from SignedInterestSha256Digest it greatly simplified operation.  I think it would be worth reviewing why it is there and what increased assurance it adds.

Marc
________________________________________
From: Zhiyi Zhang <Zhiyi.Zhang at ucla.edu>
Sent: Monday, January 14, 2019 12:07 PM
To: Mosko, Marc <mmosko at parc.com>
Cc: 侯 ?博; mini-ndn at lists.cs.ucla.edu; ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Interest Signature

On Mon, Jan 14, 2019 at 10:01 AM Mosko, Marc <mmosko at parc.com<mailto:mmosko at parc.com>> <mmosko at parc.com<mailto:mmosko at parc.com>> wrote:
(Due to a change at PARC, my current email address was not a subscriber to this list, so I had to cancel and re-post this message).

Out of curiosity, I looked through the Gerrit on the new signed interest.  I do like this direction better than the old signed interest where it is all munged in the name.

I noticed at the end of the code review comments there is the statement "The signature should not cover Name-TYPE and Name-Length."  I did not see it in the comments, but I assume you are applying the same logic to the Parameters and SignatureInfo fields?

Actually not. The reason why we don't include Name's T and L is because after generating the signature value, we need to append a SignedInterestSha256Digest component to the end of the current name, thus changing the Name's L.
This cuase extra overhead when verifying the signature -- receiver needs to calculate and modify the L before signature verification.

I think that is not correct.  When computing a digest over multiple fields, you need to delimit those fields somehow (a special character or length encoding, etc.).  Otherwise, you could have a first field with the values of the later fields and the later fields empty and get the same digest and thus the same signature.  For example, if my digest is over fields A and B, if I do not delimit them, I could have A="abc" and B="def" or A="abcdef" and B="" and they would look the same.

I think this sentence is confusing.  Maybe use more commas or break it up or use set notation.

>>> The cryptographic signature that is included in the ``InterestSignatureValue`` element covers all bytes of the ``Name`` element excluding the ``ParametersSha256Digest`` component, the Parameters element if presents, and the SignatureInfo.

It could be read that the signature _excludes_ the Parameters and SignatureInfo.  You also use "bytes" and then "component" which mixes measurements.

Thank you for your comments. I will fix this.

So it appears that the signature is only on the tuple (Name \  ParametersSha256Digest, Parameters, SignatureInfo).  Usually one would makes those contiguous memory to simplify the digest calculation, so I would have expected the BNF to have Parameters and SignatureInfo directly after Name, assuming that the BNF implies normal ordering.

That's right. I will propose this to the reviewers. (Actually I did the same things in NDN-Lite's signed Interest implementation.)

Marc

________________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu<mailto:ndn-interest-bounces at lists.cs.ucla.edu>> on behalf of Zhiyi Zhang <Zhiyi.Zhang at ucla.edu<mailto:Zhiyi.Zhang at ucla.edu>>
Sent: Saturday, January 12, 2019 11:35:33 AM
To: 侯 ?博
Cc: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>; ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: Re: [Ndn-interest] Interest Signature

Actually, we have a pending commit waiting to be merged into NDN-TLV specification: https://gerrit.named-data.net/c/NDN-TLV/+/4942
This commit defines the new NDN Signed Interest format.
Also, there is a corresponding implementation in ndn-lite library: https://github.com/named-data-iot/ndn-lite/blob/master/encode/signed-interest.h and https://github.com/named-data-iot/ndn-lite/blob/master/encode/signed-interest.c.

Hope it helps.

Best,
Zhiyi

On Fri, Jan 11, 2019 at 8:20 PM 侯 ?博 via Ndn-interest <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu><mailto:ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>> wrote:
Hello all,
I want to add signature for Interest packet. So I do some actions as follow:
Firstly, I add a member named m_signature in Interest.hpp.
Secondly, I add set and get function for this field of m_signature in interest.hpp.
Thirdly, I change the function of wireEncode and wireDecode in interest.cpp to encode and decode it.
Finally, I  add a value for m_signature  in ndn-consumer.cpp.
However, when I run the test program of ndn-simple,it shows the folloing errors，is there anyone can help me to resolve it.

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<ndn::Interest::Error> >'
what():  unrecognized element of critical type 4294967295

Thanks a lot.

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu><mailto:Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest