Subject: Re: S/MIME v3.2 IDs key size text

From: [email-masked] (Peter Gutmann)
Date: Sat, 05 Apr 2008 19:46:45 +1300

Dr Stephen Henson <[email-masked]> writes:

>Some implementations (by accident or design) restrict e to 32 bits in size.

This is actually quite useful, although the limitation in the most widespread
implementation that does this is more or less arbitrary (when they designed
their key blob format they only left 32 bits for e) it's conveniently
discouraged anyone from using large e values (well, almost anyone anyway, I
once ran into an implementation from Germany that used a 32-bit e, but also
encoded it incorrectly so anything over INT_MAX ended up negative), so it's
fairly safe to require |e| to be < 32 bits for DoS-protection purposes.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 05 Apr 2008 21:26:02 +1300

Simon Josefsson <[email-masked]> writes:

>What are the "stupid parameters" boundaries that you use?  I'd like to
>consider adopting something similar.  Using values that someone else has
>already tried appear less likely to introduce new problems.

Hmm, I wound down the limits a bit more for the latest release (e.g. the
maximum size of e has gone from 64 to 40 bits) so they haven't been as heavily
tested as the previous version, but anyway here are some of them:

For RSA:

	nLen >= MIN_PKCSIZE, nLen <= CRYPT_MAX_PKCSIZE

	e >= MIN_PUBLIC_EXPONENT, eLen < 40 bits.  The latter check is to preclude
	DoS attacks due to ridiculously large e values.

	|p-q| > 128 bits

Also for the key parameters in general:

	p, q < d
	( d * e ) mod p-1 == 1
	( d * e ) mod q-1 == 1
	( q * u ) mod p == 1
	gcd( ( p - 1 )( q - 1), e ) == 1
	e1 < p, e2 < q

For DLP-based PKCs:

	pLen >= MIN_PKCSIZE, pLen <= CRYPT_MAX_PKCSIZE.

	2 <= g <= p - 2.
	PKCS #3 keys: g < 256.  This isn't strictly necessary but use of g
		in DH typically sets g = 2, the only reason for setting it to a
		larger value is either stupidity or a deliberate DoS, neither of
		which we want to encourage.
	Non-PKCS #3 keys: g a generator of order q when the q parameter is
		present.  FIPS 186/X9.42 use a g the same size as p so we can't
		limit the size.

	y < p

If I've missed any checks, please let me know.

(Ahh, sorry the constants in the above are various configurable values, I
think the names make their function obvious).

Peter.