Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> writes:
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.
Having noted this, the field selections and names seem inappropriate: the
fact that keyInfo varies for a given key is contradictory. A preferable
organization would be to have keyInfo include the algorithm and optional
pubInfo, and put the counter in a field of its own, called keyPart, as in:
OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
keyPart INTEGER(1..2^32-1) }
KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
pubInfo OCTET STRING OPTIONAL,
keySize INTEGER OPTIONAL }
This structure is basically lifted from X9.42, so changing the
structure isn't really feasible for compatability reasons.
Changing the names while keeping the same ASN.1 doesn't seem
to add clarity.
I disagree: implementors can often be led astray by field names.
As an implementor, one of the things I hate the most is when
I try to compare two protocols and have to spend a lot of time
trying to figure out if they're the same because someone has
gratiuitously changed a bunch of stuff and I can't tell if
the changes affect the bits on the wire.
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]