[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cfrg] AES-based PRF - comment please
Uri Blumenthal wrote:
Mats Näslund wrote:
...if the desired output length is, say 256 bits, you will still
only get an effective key-size of 128, or?
The effective key size is that of the AES key size. So if one
uses AES with 128-bit key - then it's 128 bits, if AES with
256 bits - then it's 256 bits. And there's no way to make
OK, my example was using a bad choice of parameters. Replace e.g.
"256" by "384" and "128" by "256"... Of course, if
you only want to provide key material at 256 bits or less, this
is not a problem. I assumed that you also might want to e.g.
convert 2048 bits of DH key to, say 512 bits. (I really don't
have an application for this in mind, it just seems a nice
general primitive to have.)
it stronger. At least this is my understanding.
So whatever entropy the initial secret has, the resulting
entropy will be no greater than the key size of AES.
Sure, any consturction which uses something of form
1) tmp = h(S || N)
2) key = g(tmp)
will be limited by the "width" of h.
I am not sure it is generally impossible by other constructions
though (?)
But for SHA-based PRF the resulting entropy is no greater than
SHA output size (160 bits at most), and the same applies to MD5
(128 bits at most). Am I correct?
Right, with any "simple" construction.
> Also, since the OFB starts from 00....0 it seems you could have
> vulnerability to off-line pre-computation attacks.
I'm not sure I fully follow. Precomputation of the PRF output
for a bunch of assumed keys (because it shouldn't be feasible
to precompute OFB output for a reasonable-sized portion of
AES keyspace)? Could you amplify please?
*If* I have correctly interpreted your construction, it matches
the pattern of steps 1), 2) above. (If not, my aplogies.)
Let's assume that the keys are to be used for e.g. HMAC, and for
simplicity, that the attacker is able to choose plaintext, p, to be
authenticated by Alice.
The attack would be:
* generate M random values of "tmp" and expand them as in step 2)
and store valued { HMAC(k,p) }.
* sit back and watch N sessions, each HMAC:ing the message you chose,
and look for collisions in your list
Though somewhat pathologic, this seems to enable finding keys with
traditional "square root" time/memory trade off. Adding "salt" in
step 2) (or making sure that all MACs are randomized) seems to
fix this though.
Also, there are variations. One - to start OFB from the existing
buffer (which contains the key), in effect beginning OFB with
E{K}K (a non-invertible construct). Another - to skip the
first few blocks of the OFB output based on the function
of the first OFB encryption...
What would you say - does it make sense?
Well, if you randomize the srating point of the OFB, it seems fine.
In other words, there seems to be a bottle-neck just after
that step 4 that upper bounds the effective entropy, is that
right?
I doubt it's at the step 4. I'd say it's the consequence of
having a pseudo random function, whose key size effectively
defines an upper bound. No matter what, it wouldn't be
possible to create an AES-based PRF whose entropy is
greater than AES key size. I think step 4 doesn't
bring it any lower than that.
Have you looked at ISO/IEC 18033-2 ? they have a similar PRF
(mapping aribitrary length to arbitrary length) that is (if I remember
correctly) basically running SHA1 is "counter mode", keyed by the
input key.
Grrrrr. No I haven't. I will. I've taken the construct from Rijndael
paper. But as I understand form your description, ISO/IEC is similar
to what I'm doing, right?
It seems so, though I would need to re-cap.
And for precomputation attack it shouldn't matter whether CTR or OFB
mode is used, correct? Please comment.
Correct. The same TMTO attack applies also to CTR if the starting
point is not randomized properly. If it is, both seem OK.
And Mats, I appreciate your review very much. Thank you!
Sure. I think it would be nice to have an "all-AES-based" security.
It would also have been nice if the 256-bit block version of Rijndael
was standardized so that you could get 256 bit hashes using the same
primitive.
Best,
/Mats
_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg