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

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Simon Josefsson <simon@xxxxxxxxxxxxx> 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.