ietf-smime
[Top] [All Lists]

Re: Comments on x942-05 draft

1999-02-17 12:04:28
"Linn, John" <jlinn(_at_)securitydynamics(_dot_)com> writes:
In sec. 2.1.2, description of "algorithm": suggest adding the following
sentence at end: "As an implication, it may be appropriate for algorithms
employing variable parameters other than key size to be represented with
different OIDs corresponding to different parameter combinations, if
parameter values cannot be unambiguously determined from usage context".  As
a related point, would it be acceptable to state that the structure of
suppPubInfo may be defined on a per-algorithm basis?   For the case of RC2
usage in S/MIME, where the key length is fixed to 128 bits, it seems to
offer more protective value to represent the variable effective key length
within suppPubInfo than to represent the fixed 128 bit length. 
Is this necessary? The simple partition attack obviously doesn't work.
Given knowledge about the 40-bit "effective key" generated by a given
128 bit key, do you get information about the 128-bit "effective key"
that would be generated?

In 2.1.2, last paragraph, suggest rewriting "the security of the data is
limited ... even if a string longer than ZZ is generated" as "even if a
string longer than ZZ is generated, the effective key space of the KEK is
limited by the size of ZZ, in addition to any security level considerations
imposed by the parameters p and q."
I have no problem with this.

In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m MUST
be >= 160 bits in length". Later in the paragraph, is 160 bits intended as
the appropriate minimum length for p?  (Note, by comparison, that X9.42
requires a multiple of 256 bits with a minimum of 512.)
I'd prefer 160. 512 seems like overkill, and has unpleasant performance
tradeoffs.

In 2.3 and 2.4, suggest adding references to [LL97] for discussion of
additional means for generating keys which are not subject to small subgroup
attacks. 
I have no problem with this.

In the last paragraph of security considerations, suggest rewriting in terms
of security levels provided, rather than key sizes required. This makes the
discussion more relevant to particular key sizes selected, rather than
imposing recommended key sizes. In particular, suggest:

The security level provided by these methods depends on several factors. It
depends on the length of the symmetric key (typically, a 2^l security level
if the length is l bits); the size of the prime q (a 2^{m/2} security
level); and the size of the prime p (where the security level grows as  a
subexponential function of the size in bits). A good design principle is to
have a balanced system, where all three security levels are approximately
the same. If many keys are derived from a given pair of primes p and q, it
may be prudent to have higher levels for the primes. In any case, the
overall security is limited by the lowest of the three levels.
All right.

Editorial:

In 2.1.1, the description of h says "... h(p-1)/q mod p ..."; should be "...
h^{(p-1)/q} mod p ...".
Fine.

In 2.2, first paragraph, FIPS-186-1 is cited as [DSS], which doesn't appear
in the references. Given that FIPS-186-1 is currently in a review comment
period, it may be appropriate to shift this citation to point to the
finalized [FIPS-186], as included in the references section. 
Agreed.

 In the same
paragraph, there's an unmatched opening parenthesis. 
I'll fix it.

In 2.2, 2nd paragraph, "... consequently, q MUST each be ..." -> "...
consequently, q MUST be ...".
I'll fix it.

Sec. 2.4 and the security considerations section each have cross-references
as "S" rather than "Section". 
Agreed.

-Ekr


-- 
[Eric Rescorla                                   ekr(_at_)rtfm(_dot_)com]