Blake Ramsdell <blake(_at_)sendmail(_dot_)com> writes:
On Thu, Dec 06, 2007 at 04:11:52PM +1300, Peter Gutmann wrote:
How widely supported are values > 2K bits in hardware and crypto toolkits?
While I was sitting on a beach drinking Mai Tais listening to the audio of
the WG meeting, I was concerned about this exact issue.
While I was lounging on the deck of my yacht with dusky-haired maidens
whispering a summary of the WG meeting notes in ear I had exactly the same
concerns.
As for software, why is there a limitation? I admit that all of my applied
cryptogruffer experience with my own RSA implementations has been academic
(implement multi-precision integer library, modpow, admire result), but are
implementations arbitrarily stopping at some keylength, or is there some
limitation due to the implementation choice that causes a bad performance
issue, or an optimization that doesn't work over a particular keysize, or
what?
Many implementations set some sort of common-sense upper limit, typically (I'd
guess) to prevent idiots who want keys that go up to 12 or even 13 from doing
just that. See the PGP patch for using 16Kbit keys (!!!) as an example (and
this was in about 2000, when it probably would have taken half an hour just to
decrypt with one of these things).
(There's also an interop issue, if your code generates 8Kbit keys you're going
to have a serious support headache when they're not interoperable with
anything else, so there'd be a natural incentive to limits things to a sane
size).
The fact of the matter is that we need to keep increasing keylengths and
changing algorithms. Do we need to start putting in SHOULD+ recommendations
for a couple of years before putting it in as a MUST? My hope is that this
would give implementors enough time to revise for the higher keylengths.
That might be the best otion.
Peter.