[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec MIB
> > > - a list of the hashes of the keys in use
> > > might assist in debugging;
> >
> > I'll point out that this allows for exhaustive search.
>
> It just *helps* an exhaustive search, making it slightly easier
> than a known-plaintext-exhaustive-search attack.
Let me just point out that making public the hash of the secret key
can be disastrous to the security is some scenarios (I slightly elaborate
below.) So, if the intention is to publicize the hash only during development
stage than that's ok (as long as this option is later turned off). But
doing that in real deployment of the protocol is a no-no.
Assume for simplicity that Alice wants to encrypt only one word:
either "yes" or "no". Also, not trusting DES, Alice uses the most
secure encryption protocol, namely one-time-pad. That is,
the ciphertext is the cleartext xored with the key.
If Alice uses a key derived from the current ISAKMP/Oakley protocol then
the transmission will be secure. But if the protocl publishes a hash of the
key, then it's easy to find out whether the message was "yes"
or "no"! (Simply xor the ciphertext with "yes", hash, and compare with
the hashed key.)
Even if we do not know the possible messages and cannot do exhaustive
search, then by making public the hash of the key we're making a very
strong assumption on the hash function: we assume that the hash does not
reveal *any relevant information* on the key. The existing hash functions
were not designed for such a purpose and it's far from clear that they
are strong enough for this use.
Hope I'm not barging through an already open door,
Ran