The DSS spec requires that DSS keys be a multiple of 64 bits in size.
PGP has not enforced this limitation in the past, but we are adding that
now.
At the same time, we are considering requiring that newly generated keys
of the other types, ElGamal and RSA, also be multiple of 64 bits (note
that this is only enforced on keygen). The rationale is that keys of
"oddball" sizes may not be properly supported by all implementations.
We want users' keys to be able to be used in a wide range of present and
future implementations, possibly including non-PGP environments like
smartcard systems and X.509 or SPKI. By making the key sizes a nice,
round number, we improve the chances of them functioning properly in
these other environments.
Some users have already encountered a problem with oddly sized keys.
We shipped software which used Microsoft's built-in Crypto API (CAPI)
to do the RSA calculations. As it turned out, CAPI had a bug which
prevented it from working properly with unusual key sizes. Those users
weren't able to use their keys with the CAPI version.
We would like to reduce the chance of running into similar problems in
the future, and keeping keys to round sizes should help. The choice of 64
bits as the multiple is based on trading off the desire for plenty of key
sizes versus minimizing the chance of an unsupported key size. The fact
that DSS uses 64 bit multiples suggests that this is a reasonable value.
However, there is some concern that the user and developer community
may be opposed to losing this flexibility in their key size choices.
I was hoping to get some feedback here about whether this change seems
reasonable. OpenPGP participants have provided valuable feedback in the
past regarding design decisions made by NAI, often after the fact. This
time it would be helpful to find out beforehand if there will be opposition
to restricting newly generated keys in this way.
Thanks for your comments,
Hal Finney
NAI, Inc.