Re: [Cfrg] AES-based PRF - comment please

[Uri Blumenthal <uri@bell-labs.com>]

Ran Canetti wrote:
> Uri,
>
> Few remarks:
>
> 1. I think that there is some terminology confusion here with respect
> to the meaning of the name "pseudorandom function" (PRF).

Yes, it seems so.

> In the cryptographic
> theory, a PRF is an abstraction (i.e., a primitive) with specific 
> mathematical properties. Within IKE there is a construct (used for key
> derivation) that is called "PRF"; the reason for the name was that in 
> the mind of the protocol designers this construct was to be modeled as 
> a PRF in a security proof of IKE. However, there is of course no necessity 
> to model the IKE-PRF construct as a PRF. Indeed, what you seem to suggest 
> is that we can perhaps do otherwise.
OK. You're certainly correct on all te counts here.

I'm considering two choices. One is to leave this suggestion as is,
possibly tweak it a bit. Another possibility - to modify it to make
it "really" provable, but the concern here is to lose performance.

What would your preference/recommendation be?

> 2. In crypto-theory, a PRF is guaranteed to provide security only when
> its key is SECRET and RANDOM (ie, uniformly distributed).

Yes. In my mind the word "random" is stuck in the same bin as
"random number generator". "Uniformly distributed" is what it
is. Thanks for bringing this up!

> If the key is either not secret or not random then all bets are
> off - no security whatsoever is guaranteed.

I thought that the "degree" of non-randomness - i.e. fixing only
a certain part of the key - reduced the workload of adversary,
i.e. lowered the security guarantees ("resistance"), but didn't
invalidate the whole thing?


> 3. The security requirements from block-ciphers are typically aligned with
> the requirements from PRFs (or rather PRPs (pseudorandom permulations)).
> That is, security is required and analyzed only for the case where the key
> is SECRET and RANDOM. Nothing is required when the key is either not secret
> or not random.
I see.

> 4. You seem to want to construct a key-derivation function that can take 
> a bunch of inputs of variable length (some of them are secret, some public, 
> some random, some not) and somehow generate out of these a sequence of
> pseudorandom bits, which is as long as necessary. your general methodology
> is as follows:
> I. Using some hash function H, "hash down" the input material into a value 
> v that is of the right size for a PRF F. (You essentially make no distinction
> between the S input and the N input to your construct.)
> This corresponds to your steps 1-4.
Yes. I'd like to discuss with you why no distinction between S and N
is needed here.

> Your hope is that H is good enough so that v will be sufficiently
> "pseudorandom", even if the input is neither completely random nor
> completely secret. 
Yes, assuming the input contains "enough" of secret and the secret
part is distributed uniformly "enough".

> 5. While using AES for F is sound, my impression is that using AES as the 
> (essentially keyless) hash function H is rather risky and definitely not 
> well analyzed. This is not to say that it's necessarily a bad idea; rather, 
> I'd say that this requires much more justification and analysis - both in 
> terms of general cryptographic modeling and in terms of AES specifically.
> Certainly, this property that you need from H does not follow from 
> collision resistance. 
I understand. Thanks.

> (Ofcourse, the "easy way out" would be to model AES as a random oracle. 
> Then the analysis is completely trivialized and everything becomes perfectly
> secure on paper. But this is no real analysis - we know that AES is NOT
> a random oracle and we need an analysis based on realistic
> assumptions on/ modeling of AES.)
I'd like to discuss this off-line. OK?

> Hope this makes sense.
It makes a lot of sense!

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg