Subject: Comments on x942-05 draft

From: "Linn, John" <[email-masked]>
Date: Thu, 4 Feb 1999 16:11:19 -0500

Here's a small set of comments on x942-05, following discussion re x942-04.

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. 

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."

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.)

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. 

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.

Editorial:

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

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.   In the same
paragraph, there's an unmatched opening parenthesis. 

In 2.2, 2nd paragraph, "... consequently, q MUST each be ..." -> "...
consequently, q MUST be ...".

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

--jl

---

From: EKR <[email-masked]>
Date: 17 Feb 1999 11:09:50 -0800

> 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?

> imposed by the parameters p and q."
I have no problem with this.

> requires a multiple of 256 bits with a minimum of 512.)
I'd prefer 160. 512 seems like overkill, and has unpleasant performance
tradeoffs.

> additional means for generating keys which are not subject to small subgroup
I have no problem with this.

> overall security is limited by the lowest of the three levels.
All right.

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

> finalized [FIPS-186], as included in the references section. 
Agreed.

>  In the same
I'll fix it.

> consequently, q MUST be ...".
I'll fix it.

> as "S" rather than "Section". 
Agreed.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

---

From: EKR <[email-masked]>
Date: 17 Feb 1999 14:19:10 -0800

Russ Housley <[email-masked]> writes:

> John said:
> Then Eric replied:
> I do not have a problem allowing people to have 512-bit private keys.  The
> performance impact is imposed on themselves.  I also think that we should
> permit 160-bit private keys for those people that belive 80-bit security is
> useful.
> 
> In summary, I think that we should allow private keys to be between 160 and
> 512 bits.
That's no problem, but John indicates that X9.42 has a MINIMUM of 512,
which I consider unacceptable.

As far as I'm concerned people should be allowed to go up to |p|

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Feb 1999 17:16:51 -0500

Russ