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

[Zhiyi Zhang]

Thanks for the comments. They are greatly helpful!
I will make the change once I have time. I have some TA work to do first :(

Best,
Zhiyi

On Tue, Nov 20, 2018 at 11:35 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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/dcaf6646/attachment.html>