[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re-keying Issues Document
Since rekeying is current in the discussion, I'd like to take
this as an opportunity offer another thought related to rekeying.
It is suggested by some that frequent rekeying is a way to provide
perfect forward secrecy. I would like to question that hypothesis
as it applies to IPSEC, per the assumption that few platforms will
have a source of true random numbers.
For any software key generator, any new key will be predictable
given a knowledge of the algorithm and its inputs. An example
would be,
K-new = func( seed, T ),
where T is any information that varies from one invocation to the
next. T could be the previous result or a clock, or what-have-you.
In any case T is also predictable (else we're talking about random
number hardware). This will be the situation for any rekeying system
that needs to run without a source of true random numbers.
Despite any amount of rekeying, there is still really only one secret,
the seed. In other words, in the absence of a true random number source,
the cryptographic problem has only been transformed by "func( seed, T)",
such that the secret is now the "seed" rather than the "key". For a brute
force attack, the attacker simply chooses a seed and then generates the
corresponding key(s).
(Parenthetical note: The additional cost in computation to explore a
field of seeds, can probably be made trivial, using a suitably designed
machine.)
>From the above, we see that there is no such thing as software generated
perfect forward secrecy. But, the situation might be actually worse than
that.
Consider the possibility that all of the values "K-new" consitute a group
related to "seed". In that case, as we repeatedly generate "K-new" we
are sampling that group. Therefore, when we use the numbers to encrypt
messages, it might be that we are giving away information about the
cryptographic secret. That the messages are IP datagrams (which tend to
include some portion of predictable content), would make this even-more-so.
(Another parenthetic note: Perhaps ways can be found to attack some
specific combinations of rekeying function and cipher.)
If this is true, then in the absence of hardware random number generators
on both ends, it would seem better to simply start off with a larger key
and only rekey when motivated by some security signal and only using reliable
sources of random numbers.
The need for hardware random number generators at both ends (in this argument)
can be seen on considering the D-H algorithm. The common secret is available
to either party based on that party's secret and the other party's public key.
Regards to all,
Mitch Nelson
Follow-Ups: