Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
I don't see how this makes any difference. Remember, all we're talking
about is the data that's input to the key expansion function. The
actual parameters that are to be used have to be conveyed separately
in any case, because this data is subsequently hashed. The only real effect
of including the algorithmId at all is to produce different keys for
different algorithms using the same pubInfo. It could easily be omitted
entirely.
I think you are missing an important point. RC2 with a 40 bit key and RC2
with a 128 bit key result in the same inputs to the hash algorithm. If an
attacker is able to get a less sensitive message to be encrypted with the
40 bit key, this message can be readily attacked by brute force. Should a
more sensitive message be encrypted with the 128 bit key, the attacker
already knows the first 40 bits of the key.
This is incorrect. By fiat, when used for key encryption, RC2 ALWAYS
uses a 128 bit key. The 40 bits refers only to the effective key length.
It may be possible to go from the 40 bit key to having some information
about the 128 bit key, but it's certainly not as simple as simply
knowing the first 40 bits.
And, the fix is
very simple. We need to simply include the key length in the hash input.
I'm prepared to do it, but I'm not sure that just shoving it in the
pubInfo is the right choice. I'll think about this and try to write
up a proposal by monday.
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]