<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I submitted a pull request for adding SignatureHmacWithSha256</div>
<div><a href="https://github.com/named-data/NDN-TLV/pull/1">https://github.com/named-data/NDN-TLV/pull/1</a></div>
<div><br>
</div>
<div>For convenience, the text is below. I am especially interest in feedback on the languages about provenance: "Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties which holds
 the shared <tt class="docutils literal">Key</tt>. The key is identified using a <tt class="docutils literal">KeyDigest</tt> as described above. It is the application’s responsibility to establish the identities of the parties who hold the shared <tt class="docutils literal">Key</tt>."</div>
<div><br>
</div>
<div>- Jeff T</div>
<div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="signature">
<div class="section" id="keylocator">
<div class="section" id="signaturehmacwithsha256">
<h3>SignatureHmacWithSha256<a class="headerlink" href="cid:6B94E289-C6DC-4002-9EF9-948D08AD1503" title="Permalink to this headline" type="text/html"></a></h3>
<p><tt class="docutils literal">SignatureHmacWithSha256</tt> defines a hash-based message authentication code that is calculated over the
<a class="reference internal" href="cid:AC18F89D-17C3-42FC-9E01-3D98C498CF70" type="text/html">
<em>Name</em></a>, <a class="reference internal" href="cid:FAADCD52-F5F2-4B4F-8F23-8572A094F60B" type="text/html">
<em>MetaInfo</em></a>, <a class="reference internal" href="cid:63CEF72F-159E-490F-ACCD-10B291183891" type="text/html">
<em>Content</em></a>, and <a class="reference internal" href="cid:4BC39041-4470-4AAE-A916-93EFAFB2F6C0" type="text/html">
<em>SignatureInfo</em></a> TLVs, using SHA256 as the hashing function. The signature algorithm is defined in
<a class="reference external" href="http://tools.ietf.org/html/rfc2104#section-2">
Section 2 in RFC 2104</a>.</p>
<div class="highlight-python">
<div class="highlight">
<pre>SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 4
                    KeyLocator

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
                     BYTE++(=SHA256({KeyValue XOR opad, SHA256({KeyValue XOR ipad, Name, MetaInfo, Content, SignatureInfo})}))
</pre>
</div>
</div>
<p>where</p>
<div class="highlight-python">
<div class="highlight">
<pre>opad = 0x5c5c5c...5c5c5c (repeated 64 times)
ipad = 0x363636...363636 (repeated 64 times)
</pre>
</div>
</div>
<p><tt class="docutils literal">Key</tt> is a shared key known to the sender and receiver of the signed packet.
<tt class="docutils literal">KeyValue</tt> is derived from a shared <tt class="docutils literal">
Key</tt> as follows. If the byte length of <tt class="docutils literal">Key</tt> is less than the SHA256 block length (64 bytes) then append zeros to the end of the
<tt class="docutils literal">Key</tt> to create the 64-byte <tt class="docutils literal">
KeyValue</tt>. If the byte length of <tt class="docutils literal">Key</tt> is greater than 64 bytes then hash it with SHA256 to produce a 32-byte value then append 32 zeros to the end to create the 64-byte
<tt class="docutils literal">KeyValue</tt>. (The HMAC functions in most cryptographic libraries are supplied the
<tt class="docutils literal">Key</tt> and will internally derive the <tt class="docutils literal">
KeyValue</tt> in this way.)</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><tt class="docutils literal">Key</tt> is not included in the signature. It is the application’s responsibility to ensure that the receiver already knows the shared
<tt class="docutils literal">Key</tt>. It can be identified using a <tt class="docutils literal">
KeyDigest</tt> as the <a class="reference internal" href="cid:91E28A76-B2E3-4C4A-A5C6-B21BBE7AF358" type="text/html">
<em>KeyLocator</em></a> block in the <a class="reference internal" href="cid:D9F93FE6-7AA5-4798-94A4-F9C08EEEF53D" type="text/html">
<em>SignatureInfo</em></a> block of <tt class="docutils literal">SignatureHmacWithSha256</tt> as follows. If the byte length of
<tt class="docutils literal">Key</tt> is less than or equal to the SHA256 block length (64 bytes) then the
<tt class="docutils literal">KeyDigest</tt> is SHA256(<tt class="docutils literal">Key</tt>). But if the byte length of
<tt class="docutils literal">Key</tt> is greater than 64 bytes, the <tt class="docutils literal">
KeyValue</tt> is already SHA256(<tt class="docutils literal">Key</tt>) with zeros appended, so in this case
<tt class="docutils literal">KeyDigest</tt> is SHA256(SHA256(<tt class="docutils literal">Key</tt>)).</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As stated in in <a class="reference external" href="http://tools.ietf.org/html/rfc2104#section-3">
Section 3 of RFC 2104</a> , keys shorter than the SHA256 output byte length (32 bytes) are strongly discouraged.</p>
</div>
<p>Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties which holds the shared
<tt class="docutils literal">Key</tt>. The key is identified using a <tt class="docutils literal">
KeyDigest</tt> as described above. It is the application’s responsibility to establish the identities of the parties who hold the shared
<tt class="docutils literal">Key</tt>.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sidebar">
<h3><br>
</h3>
</div>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><Thompson>, Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Date: </span>Monday, March 9, 2015 at 6:07<br>
<span style="font-weight:bold">To: </span>Yingdi Yu <<a href="mailto:yingdi@cs.ucla.edu">yingdi@cs.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Ndn-interest] Adding HMAC to available NDN signature types<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Yingdi,</div>
<div><br>
</div>
<div>Following up to your message (6 months ago):</div>
<div><br>
</div>
<div>> Moreover, how to definition of KeyDigest is important in the validation part, so that data consumers can determine which symmetric key should be used to verify the HMAC. I agree with Marc that, for key longer than the block size, we can use the digest
 of digest of the key as the key id because the digest of the key is the actual key in this case.</div>
<div><br>
</div>
<div>Agreed for KeyDigest. The KeyLocator can also a key Name but normally a key Name is used to fetch a certificate which has more info. But there is not certificate for HMAC so would you agree that we only describe a KeyDigest for the KeyLocator?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>- Jeff T</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Yingdi Yu <<a href="mailto:yingdi@cs.ucla.edu">yingdi@cs.ucla.edu</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, September 23, 2014 at 9:51<br>
<span style="font-weight:bold">To: </span>Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>Adeola Bannis <<a href="mailto:abannis@ucla.edu">abannis@ucla.edu</a>>, "<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Ndn-interest] Adding HMAC to available NDN signature types<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div><span style="text-align: -webkit-auto; orphans: 2; widows: 2;">Hi Jeff,</span></div>
<div><span style="text-align: -webkit-auto; orphans: 2; widows: 2;"><br>
</span></div>
<span style="text-align: -webkit-auto; orphans: 2; widows: 2;">On Sep 22, 2014, at 10:02 AM, Thompson, Jeff <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>> wrote:</span><br>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hash output length vs. block size…</div>
<div><br>
</div>
<div>Marc is right. The HmacWithSha256 algorithm hashes the key when it is longer than the block size (64 bytes), not the hash output length (32 bytes).  So we would prohibit keys longer than 64 bytes (not 32 bytes).</div>
</div>
</blockquote>
<div><br>
</div>
In Adeola's spec, the block size is not required to be 64 bytes. The RFC does not require the block size to be 64. I wonder if we should clarify that in the spec?</div>
<div><br>
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;">
<div>Also, most applications will use a crypto library's HMAC function which should automatically hash the key if it is longer than the block size. It could be confusing to put this in the spec since the application writer may unnecessarily has the key when
 the crypto library will do it anyway, and more efficiently.</div>
</div>
</blockquote>
<br>
</div>
<div>I think the purpose of this spec is not only for application developers, but also for library developers, especially if we want to have good interoperability. So I think it would be better to clearly specify what is the requirement of generating a signature,
 how to generate a signature and what should be put into the SignatureInfo.</div>
<div><br>
</div>
<div>Moreover, how to definition of KeyDigest is important in the validation part, so that data consumers can determine which symmetric key should be used to verify the HMAC. I agree with Marc that, for key longer than the block size, we can use the digest
 of digest of the key as the key id because the digest of the key is the actual key in this case.</div>
<div><br>
</div>
<div>Yingdi</div>
<br>
</div>
</div>
</span></div>
</div>
</span>
</body>
</html>