[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment regarding Nonce size
Andrew,
I agree with what you say below except for one caveat:
how much you trust the randomness of your peer's nonces?
If you form the prf key as Ni|Nr as currently done in IKE
then you are assuming goos (pseudo) randomness of both nonces.
An option is to replace Ni|Nr with Ni XOR Nr which means that it suffices
for one of the nonces to be random for the result to be random too.
The reason that we did not use this in IKE is due to nonce length
consideration (bandwidth) and also the concern that
by doing Ni XOR Nr the responder could actually (maliciously)
set Ni XOR Nr to whatever value it wants (e.g. 0). However,
this may not be a concern that we should address since if R is malicious
and tries to weaken the exchange it has many other ways to do it
(e.g. choosing its DH exponent as g^2 or posting the exchanged key
in the web :).
So the two main options I see are:
1) YOu trust the nonce randomness of both sides (yours and your peer)
and then you put the length of the nonce to be 1/2 the length of
the prf key (e.g., 80 in the case of HMAC-SHA1) and concatenate
Ni|Nr in the key derivation part.
2) You do not necessarily trust the randomness of your peer and then
each chooses a nonce of the full length of the prf key (160 in the case of
HMAC-SHA1) and put the key to be Ni XOR Nr.
If bandwidth considerations are significant the first (current IKE method)
seems good enough to me.
Hugo
On Fri, 14 Dec 2001, Andrew Krywaniuk wrote:
> > PS: the above paragraph about the pre-hashing of long keys in
> > HMAC also
> > gives you a partial answer on your other question
> > about what's the benefit of using nonces that are longer than the hash
> > output size: while the extra length is not strictly needed, and can
> > even be considered a "waste" if the nonce bits are TRULY random,
> > the extra length may potentially help in the typical case
> > that these bits
> > are generated out of a weaker source of (pseudo) randomness.
>
>
> It seems to me that this is only an advantage if you have a weak RNG but you
> don't know it. If you think you have a weak RNG, wouldn't a better solution
> be to generate a large nonce with sufficient entropy and then hash it down
> to the size of the HMAC output? That would save bits on the wire, with no
> apparent drawbacks.
>
> Andrew
> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.
>
>
>
References: