Per Russ' solicitation for review of smime-x942-04 by cryptographers, I'm
forwarding the attached comments provided to me by Burt Kaliski and Yiqun
Lisa Yin of RSA Laboratories.
--jl
1. In general, the draft is a nice condensation of the ANSI X9.42 draft into
IETF S/MIME terms.
2. ANSI X9.42 is still an unapproved draft, and should be cited as such, not
as a standard.
3. The shared secret value ZZ is sometimes called a shared secret number.
"Value" would be better throughout, since in more general settings, ZZ is a
finite field element, not a number (integer).
4. Section 2.1.1: An operator is missing in the definitions of g and h,
which should be
g = h^{(p-1)/q} mod p ...
h is any integer ... such that h^{(p-1)/q} ...
In this definition, it could be clarifying to state that the parameters are
(p,q,g) and to change the order of definitions to:
p is a large prime
q is a large prime such that p = qj+1 for some larger integer j
g = h^{(p-1)/q} mod p where ...
Further, it may be helpful to explain that "g has order q mod p" means that
g^q mod p = 1, if g <> 1 and q is prime.
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. Also, the comment "the
security of this data is limited to the size of ZZ" is not accurate. The
security is related to the size of p and q. A large ZZ doesn't imply
security by itself.
6. Section 2.1.2: Editorial: Change "shared key" to "shared secret value".
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.
8. Section 2.1.2: "Parameters" is misspelled in the definition of the
algorithm field.
9. Section 2.1.2: Some additional explanation would be helpful about the
relationship between KM and a KEK. In particular, the text might say that to
generate a KEK, one generates one or more KMs from the same ZZ, where
OtherInfo varies. The variable part of OtherInfo is keyInfo; pubInfo remains
the same.
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 }
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.
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.
Also, random or nonce might be a better name, since all of otherInfo, not
just pubInfo, is public.
12. In general, the different terms for byte ordering should be harmonized
or adopted from some other standard: "leftmost", "network byte order", etc.
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.
14. Section 2.1.5: Editorial: Change "received public keys" to "a received
public key y".
Also, add a reference to IEEE P1363 security considerations for more
discussion on public-key validation.
15. Section 2.1.6: This 16-byte example doesn't comply with the draft's
160-bit minimum (Section 2.2).
16. Section 2.2: Should a lower bound on the prime p also be given? Why is
there a 160-bit minimum on q? (Note that the 128-bit minimum in the same
paragraph is inconsistent.) Also, a minimum size on the private key x is
inconsistent with saying that x is in the interval [2,q-2].
The first paragraph of this section is missing a parenthesis.
Per Sec. 2.2.1.1, we believe that it would be appropriate for the document
to state explicitly that alternate parameter generation algorithms MAY be
used; P1363 can be cited for discussion. Per Sec. 2.2.1.1, step 6, it would
be useful to give a reference to what primality algorithm(s) can be used.
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.
Editorial: Change "If the sender cannot" to "If an opponent cannot"; change
"failure of decryption" to "failure of a decryption operation by the
recipient".
18. General: Replace "S" with "Section" for cross-referencing.
19. Security considerations. The last two paragraphs could be merged into
Sections 2.1.5 and 2.2, or at least should be made consistent, so there are
not two sources for the same information.
In the last paragraph, the effective length of 3DES keys is 112, not 168,
due to a meet-in-the-middle attack.
In a general design, one looks for a minimum security level and selects
algorithms to meet that level. So, for instance, if an 80-bit security level
is desired, a designer may choose 3DES or RC2 and a 160-bit minimum
subgroup. Selecting the subgroup size to be double the effective key
strength, while effective, is more than what is necessary. The subgroup size
should be double the desired security level rather than double the symmetric
key size.
Moreover, there needs to be a prime size selection (1024 bits, 2048 bits,
etc.) that matches the desired level.
Finally, the selection must take into account the number of users sharing
the primes, since it costs only slightly more to compute several discrete
logarithms than to compute the first one.