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

[Robert Moskowitz <[e-mail]>]

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.