Maximum keypair length...

[Peter Pentchev]

On Thu, May 07, 2020 at 07:33:06AM -0400, Barry Smith via Gnupg-users wrote:
[formatting fixed; top-posting considered weird]
> On Fri, May 1, 2020, 12:01 Konstantin Ryabitsev <
> konstantin at linuxfoundation.org> wrote:
> 
> > On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users
> > wrote:
> > > Let me continue by explaining some back up information for my
> > > question.
> > > - I am asking in terms of the latest standards implemented in distros and
> > > Windows .exe auto-install packages.
> > > - I am trying to create a group calendar file and app for a private
> > group.
> > > - Original concept for my project -- use an annual calendar file that has
> > > December (year minus 1) to January (year plus 1), so 14 months of days. I
> > > want one keypair per day for the group.
> >
> > I'm not sure what kind of risk scenario you're working against, but this
> > sounds extreme and will probably have all sorts of usability corner
> > cases.
> >
> > > SO, users, help!
> > > I need to know the absolute longest key that GnuPG can create RIGHT
> > > NOW.
> >
> > It depends on the algorithm. RSA keys have the default maximum length of
> > 8192 set at compile-time. Elliptic Curve cryptography requires much
> > shorter keys, so maximums will be different there.
> >
> > In general, the length of the key is only part of the picture when we're
> > talking about encryption "strength." Many cryptographers consider RSA
> > keys longer than 2048 bits to be a "feel-good security theatre", because
> > classical computers are not likely to be able to successfully break
> > 2048-bit keys in the foreseeable future, even given state-level funding.
> > If/once we get to the point where quantum computers are powerful enough
> > to defeat 2048-bit RSA, then we should consider all classical public-key
> > crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair
> > lengths will merely buy a bit of time before failing to cryptanalysis.
> >
> > So, if you want decent modern-day encryption, use 256-bit ECC keys and
> > don't worry about key lengths longer than 256 (or 4096 for RSA).
> >
> > -K
> 
> Thank you for your excellent response.
> 
> I laid out my scenario.
> >>
> RSA keys have the default maximum length of
> 8192 set at compile-time.
> >>
> Perfect. that was the answer that
> I was looking for.
> My "risk scenario" was an attempt to understand the maximum defaults of the
> current maximum protection available in the standard distributed packages.
> 
> From the position of a data scientist, I am trying to compute the security
> available. ;)
> 
> Thank you... 8196 on an RSA key. :)

Leaving aside the fact that I agree with Konstantin about the pure
futility of using 8K RSA keys (but, well, if you're asking from
the standpoint of "this is something that somebody who wants to use
my program at some point in the future may want"... but even from
that standpoint, there may also be people who build their own
versions of cryptography tools with even crazier limits, so even
8K might not be enough)...

...so leaving all that aside, when you speak of field lengths,
you do realize, don't you, that the raw key material is only
a part of even the information that is stored in the keyring,
not to mention the information that is exported as a certificate
(what most people think of when they say "my public key")?
There are user IDs, there are self-signatures, there are
signatures from other parties that let you actually trust
the key... and most of these do not really have a fixed
count, limit, or length. Then there is the export format,
the fact that if you want to transmit the key and certificate
through a text medium, you'll have to encode it and make it
even larger...

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200507/fb24fed0/attachment.sig>