Eric:
7. Section 2.1.2: Identifying an algorithm by an OID rather than an
AlgorithmID risks losing some specifics about the algorithm. For
instance,
in a variable-key-size block cipher (e.g., RC5), the AlgorithmID
carries the
key size, so this information would be lost. As a result, it may be
possible
for an opponent to substitute a key of one size for a key of a different
size, which may lead to an attack that recovers the key one part at a
time.
Presumably, the reason for avoiding a full AlgorithmID is that some
of its
parameters are message-specific, such as IVs, but perhaps there is some
middle ground. Including the key size as an optional field of
OtherInfo is
one possibility. Other parameters that will be lost in the case of
RC5 are
the block size and the number of rounds.
I think this is weird, but this is how X9.42 does it, so our
choices are kind of limited.
This worries me. If there is a substitution attack that can recover the
key, I think we need to look at it VERY CAREFULLY. Has this same topic been
discussed on the X9.42 list? If so, can someone summarize the result? If
not, why not?
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.
Off the top of my head, I am not sure how the attacker can get this
situation to happen with S/MIME v3, but I am in favor of a robust security
standard. We know that people are looking at CMS for other purposes. One
of those future uses may permit an attack like this one. And, the fix is
very simple. We need to simply include the key length in the hash input.
Russ