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

[Zhiyi Zhang]

Hi Junxiao,

I just updated the NDNCERT spec.
I addressed your comments regarding KDF and also added the draft of
revocation.

Best,
Zhiyi

On Tue, Nov 20, 2018 at 12:25 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:

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