Eric, John, et. al.:
5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so
some conversion to an octet string is required. The usual conversion,
following IEEE P1363 and ANSI X9.42, is a most significant byte first
representation. ANSI X9.42 specifies that the result has as few bytes as
possible (i.e., no leading zeros); IEEE P1363 says that the result has the
same length in octets as the longest field element (i.e., the length of the
prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI
X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI
X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed.
In any case, some representation should be stated.
Agreed. Myself I prefer fewest octets.
I disagree with Eric.
I believe that ZZ should be the same size as p. I think that this is much
easier to implement. An implementation must have a buffer the size of p
since the result of the exponentiation could have no leading zero octets.
So, the implementation can simply use the entire buffer as the first input
to the hash function.
I have asked a couple implementors what they do. So far, I have not found
anyone that is dropping leading zero octets.
It turns out that the ANSI X9F1 working group was meeting today. Good
timing. The ANSI X9F1 working group discussed this comment, and the ANSI
X9.42 draft will be changed to align with IEEE P1363.
To me, these three points are compelling. I strongly suggest that we adopt
Burt's and Lisa's recommendation.
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.
I think it would be inappropriate to assign OIDs that did not contain
message-specific data, such as IVs. Assigning additional OIDs does not
seem to be the way forward.
This "partition attack" is a real concern. That input to the hash function
must unambiguously identify the output key length. However, I think that
there is a way forward. The key length is either implicit from the
algorithm identifier (e.g., DES) or it is carried as a parameter in the
algorithm identifier (e.g., RC2). So, the recipient can easily determine
the value to pass to the key derivation function. Perhaps we can always
put the key length in the pubInfo. If a UKM is present, the pubInfo can be
the concatenation of the key length and the UKM.
What do others think about this approach? If this approach is acceptable
to everyone, then we need work out the exact encodings.
10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the
unnecessary definition of an encoding format for the counter, while
maintaining an unambiguous encoding.
Again, this is how X9.42 does it.
This is done to aid implementors. By making the field fixed length, an
implentation can use a constant to initialize OtherInfo. Then, the counter
portion is incremented for each invocation of the Hash function.
11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512
bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding
as an OCTET STRING is unambiguous and prevents length-extension attacks.
Russ, you care to speak up on this?
Since the internal block size of SHA-1 is 512 bits, this seems to be the
maximum amount of entorpy that can be added with a public value.
This comment would indicate that sizes between 160 and 512 bits are useful.
Should we standarize on a single length? 512 bits?
13. Section 2.1.3: KEK computation states that each algorithm requires a
specific size key. But some algorithms have variable-size keys, and it's
possible that future algorithms will require more than just a random string
(e.g., more structure). So, it would be preferable to say that the currently
proposed S/MIME algorithms assume a random string, perhaps with parity
changes.
Well, the output of this process is necessarily a random string. Any
algorithm which needs a key with more structure should have a pre-processor
which produces one from a bit string.
I agree with Eric. I do not think that we can anticipate the needs of
these future algorithms. Rather, when a future algorithm is defined, a
mapping between the "random" X9.42 output and the structured input needed
by the algorithm can be defined.
16. Section 2.2: Should a lower bound on the prime p also be given?
Probably. 1024 and be done with it?
Eric, I assume that you mean p must be at least 1024 bits long. Not, p
must be greater than 1024.
17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a
small-subgroup attack. Another method is cofactor multiplication, as
described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an
additional operation on the shared secret value so that it is not in a small
subgroup. (There is a "compatibility mode" that keeps the shared secret
value the same as in ordinary Diffie-Hellman when the system is not under
attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor
multiplication for Diffie-Hellman primitives. Electronics Letters,
34(25):2396-2397, December 10, 1998.)
Another method is to choose the primes p and q so that p = qj + 1 where j is
small and to check the received public key against a small set of excluded
values. In this case, the leakage due to a small subgroup attack will be
only a few bits.
I have to admit that I'm not enough of a mathematician to have
an informed opinion on this topic. I'd certainly far rather not
change the shared-secret value, and I don't want to require
an extra operation either (for perforamnce reasons).
Eric, your response here does not tell me what you plan to do. Do you
know yet?
Russ