Re: [Cfrg] draft-irtf-cfrg-kdf-uses-00

["Dan Harkins" <[e-mail]>]

  Hi Bob,

  I don't know what the protocol is but if you added a nonce exchange
to the DH exchange (and had appropriate assumptions on the randomness
of the nonces) then you could use the nonces as the key to the CMAC-based
KDF and the DH shared secret as (part of) the data that's MAC'd.

  regards,

  Dan.

On Wed, March 24, 2010 11:42 am, Robert Moskowitz wrote:
> David suggested I bring this discussion to the list.
>
> As I have mentioned previously on this list, I want a CMAC based KDF
> where the key was derived from a DH exchange.  As you will see below,
> per this ID, CMAC can only be used as a KDF (and this is the case in its
> use in NIST 800-108) if the key is uniformly distributed (use case #3).
>
> So scan down to the important stuff....
>
> On 03/24/2010 07:30 AM, David McGrew wrote:
>> Hi Robert,
>>
>> On Mar 23, 2010, at 6:55 PM, Robert Moskowitz wrote:
>>
>>> Further questions...
>>>
>>> Does ECDH keys also fit in use case #2?
>>
>> yes, this use case was meant to cover any public key algorithm whose
>> output is a value that is secret, but which is not a binary string
>> that is uniformly randomly distributed.
>>
>>>
>>> Can you define a KDF for #2 that uses CMAC? It seems from your
>>> document that current there is not one.
>>>
>>
>> Not if you want provable security.
>>
>> From http://people.csail.mit.edu/dodis/ps/hmac.ps:
>>
>> The Extraction Properties of CBC-MAC Mode. We show, in Section 3, that
>> if f is a random permutation over
>> {0, 1}^k and X is an input distribution with min-entropy of at least
>> 2k, then the statistical distance between F (X) (where F represents
>> the function f computed in CBC-MAC mode over L blocks) and the uniform
>> distribution on {0, 1}^k is L · 2^{−k/2}.
>>
>> In practice, using this proof of security would mean that public keys
>> providing 4*n bits of security would be needed in order to be provably
>> secure at the n-bit level.  For ECC, this would mean we'd need to use
>> 1024-bit keys (four times 256 bits) in order to claim 128 bits of
>> security based on something "provable".  So in short it seems that if
>> one demands "provable security", this is not a good way to go.
>
> I ASSuME you mean used in an ECDH key agreement to get the non-uniformly
> distributed key?
>
>>
>> There might be more recent results, but I'm not aware of any.   It
>> would be useful to take this discussion to the list, if you don't
>> mind.  "I want an AES-based KDF for use case #2" is a good topic for
>> discussion.
>
> OK, I am trying to Grok this...
>
> Does CMAC have the same extraction properties as CBC-MAC?
>
> Someone mentioned that you should first run the DH output through a
> function that uniformly distributes the randomness, then feed it into
> CMAC.  But what would that be if not a hash function?  And it has to be
> tight enough code that it is a reasonable alternative.
>
> Is my only alternative for a 'light weight keying' to pitch DH and just
> deliver a random key encrypted with a public ECC key?   Then I fit in
> case #3 and can use CMAC?  Though an arguement can be made that you want
> to pitch DH as well when you strive for a real small code size and low
> CPU hit.
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>