<div dir="ltr">Hi Zhiyi<br><div class="gmail_quote"><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.2 NEW Data: what signature verification, if any, is the requester required to perform?</div><div>Section 2.3.3 SELECT Interest: is an <a href="https://en.wikipedia.org/wiki/Key_derivation_function" target="_blank">key derivation function</a> applied on the ECDH premaster secret to derive the AES key?</div></div></div></div></div></div></div></blockquote><div><br></div><div>No. The default ECDH for NDNCERT 0.2 is over curve p-256 and thus the shared secret will be 256 bits, which can be directly used for AES-256 Encryption.</div><div><br></div></div></div></blockquote><div><br></div><div>Our <a href="https://www.nist.gov/people/kerry-mckay">crypto expert</a> believes it is necessary to use a key derivation function. I asked her regarding this use case, and the answer is:</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt">There are several reasons why
a KDF might be used, but since we’re not talking about session-based keys, I
will focus on just two reasons: key quality and target security strength.</span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt"> </span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:12pt">Key quality:</span></b></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt">While key length can be used
as a simple security metric, it comes with an assumption: that the key is
selected at random from a uniform distribution. This is not achieved by a DH
key agreement. Here’s a quick example to show why (using finite fields instead
of elliptic curves for illustrative purposes):</span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt"> </span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt">Suppose that we needed to key
a 4-bit block cipher. We perform a DH key agreement with a group having prime
p=11 and generator g=2. All results of the key agreement will be in the range
[1, … 10], which is represented in 4 bits, so we might think that we could
directly use this. This would not meet the assumptions of a strong key though,
because the assumed key space for the cipher is [0, …, 15]. Because 0 and 11-15
are not possible keys, we don’t get the necessary randomness, and thus have low
key quality for a block cipher.</span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt"> </span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:12pt">Target security strength:</span></b></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt">Security strengths by key
length vary by algorithm type. In particular, keys are larger in asymmetric
algorithms than the security that they provide. ECDH with curve P-256 only
provides up to 128 bits of security. So the design is effectively keying
AES-256 with a maximum of 128 bits of security. For this scenario with P-256,
the result of the ECDH exchange should be put through a KDF to get a
[high-quality] 128-bit AES key, and then used with AES-128. This achieves a
consistent 128-bit security strength. If AES-256 is truly desired, then a curve
that provides a higher security strength should be paired with it.</span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt"> </span></p></div></div><div class="gmail_quote"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt">See <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf" style="color:rgb(5,99,193)">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf</a>,
appendix D, table 24 for targeted security strengths of different elliptic
curves.</span></p></div></div></blockquote><div class="gmail_quote"><div><br></div><div>Based on this answer:</div><div>KDF should be required. Most KDFs require a "salt", so be sure to design how to encode and transmit that value.</div><div>AES-128 should be used instead of AES-256. Although you have the option of using a curve stronger than P-256, it would cause implementation difficulty on microcontrollers (e.g. ECC508 chip only supports P-256), so I hope you don't go that way.</div><div><br></div><div><br></div><div>Yours, Junxiao </div></div></div>