Simon Josefsson <simon(_at_)josefsson(_dot_)org> 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.