[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

[Junxiao Shi]

Hi Zhiyi


>
>> Section 2.3.2 NEW Data: what signature verification, if any, is the
>> requester required to perform?
>> Section 2.3.3 SELECT Interest: is an key derivation function
>> <https://en.wikipedia.org/wiki/Key_derivation_function> applied on the
>> ECDH premaster secret to derive the AES key?
>>
>
> 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.
>
>
Our crypto expert <https://www.nist.gov/people/kerry-mckay> believes it is
necessary to use a key derivation function. I asked her regarding this use
case, and the answer is:

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.



*Key quality:*

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):



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.



*Target security strength:*

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.



See
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf,
appendix D, table 24 for targeted security strengths of different elliptic
curves.


Based on this answer:
KDF should be required. Most KDFs require a "salt", so be sure to design
how to encode and transmit that value.
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.


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181120/7a676544/attachment.html>