Maximum keypair length...

[Barry Smith]

Thank you, Peter.

My question is purely about the security of the encryption.
There is no need in my proposed scenario for extra signing or overhead.

Understand that I am suggesting the creation of a set of keys, one per day,
less than 33 keys, generated by one central admin.

Second, i am looking to export the "sec" file for each calender day key...
so that EACH group member will recieve both the pubkey AND the sec key on
the group keyring from the group admin.

Again, my focus was NOT on signatures or "bloat" involved in the keyring.
My focus is on security.

Thank you for your inclusion of valid points, but my point is only on
security for group communication, not overhead involved in keyring export
size. :)

thank you. :)

On Thu, May 7, 2020, 11:00 Peter Pentchev <roam at ringlet.net> wrote:

> 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 partied 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200508/19a05091/attachment-0001.html>