<div dir="auto"><div>Thank you, Peter.<div dir="auto"><br></div><div dir="auto">My question is purely about the security of the encryption.</div><div dir="auto">There is no need in my proposed scenario for extra signing or overhead.</div><div dir="auto"><br></div><div dir="auto">Understand that I am suggesting the creation of a set of keys, one per day, less than 33 keys, generated by one central admin.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div>Again, my focus was NOT on signatures or "bloat" involved in the keyring. My focus is on security.</div><div dir="auto"><br></div><div dir="auto">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. :)</div><div dir="auto"><br></div><div dir="auto">thank you. :)<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 11:00 Peter Pentchev <<a href="mailto:roam@ringlet.net">roam@ringlet.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 07, 2020 at 07:33:06AM -0400, Barry Smith via Gnupg-users wrote:<br>
[formatting fixed; top-posting considered weird]<br>
> On Fri, May 1, 2020, 12:01 Konstantin Ryabitsev <<br>
> <a href="mailto:konstantin@linuxfoundation.org" target="_blank" rel="noreferrer">konstantin@linuxfoundation.org</a>> wrote:<br>
> <br>
> > On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users<br>
> > wrote:<br>
> > > Let me continue by explaining some back up information for my<br>
> > > question.<br>
> > > - I am asking in terms of the latest standards implemented in distros and<br>
> > > Windows .exe auto-install packages.<br>
> > > - I am trying to create a group calendar file and app for a private<br>
> > group.<br>
> > > - Original concept for my project -- use an annual calendar file that has<br>
> > > December (year minus 1) to January (year plus 1), so 14 months of days. I<br>
> > > want one keypair per day for the group.<br>
> ><br>
> > I'm not sure what kind of risk scenario you're working against, but this<br>
> > sounds extreme and will probably have all sorts of usability corner<br>
> > cases.<br>
> ><br>
> > > SO, users, help!<br>
> > > I need to know the absolute longest key that GnuPG can create RIGHT<br>
> > > NOW.<br>
> ><br>
> > It depends on the algorithm. RSA keys have the default maximum length of<br>
> > 8192 set at compile-time. Elliptic Curve cryptography requires much<br>
> > shorter keys, so maximums will be different there.<br>
> ><br>
> > In general, the length of the key is only part of the picture when we're<br>
> > talking about encryption "strength." Many cryptographers consider RSA<br>
> > keys longer than 2048 bits to be a "feel-good security theatre", because<br>
> > classical computers are not likely to be able to successfully break<br>
> > 2048-bit keys in the foreseeable future, even given state-level funding.<br>
> > If/once we get to the point where quantum computers are powerful enough<br>
> > to defeat 2048-bit RSA, then we should consider all classical public-key<br>
> > crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair<br>
> > lengths will merely buy a bit of time before failing to cryptanalysis.<br>
> ><br>
> > So, if you want decent modern-day encryption, use 256-bit ECC keys and<br>
> > don't worry about key lengths longer than 256 (or 4096 for RSA).<br>
> ><br>
> > -K<br>
> <br>
> Thank you for your excellent response.<br>
> <br>
> I laid out my scenario.<br>
> >><br>
> RSA keys have the default maximum length of<br>
> 8192 set at compile-time.<br>
> >><br>
> Perfect. that was the answer that<br>
> I was looking for.<br>
> My "risk scenario" was an attempt to understand the maximum defaults of the<br>
> current maximum protection available in the standard distributed packages.<br>
> <br>
> From the position of a data scientist, I am trying to compute the security<br>
> available. ;)<br>
> <br>
> Thank you... 8196 on an RSA key. :)<br>
<br>
Leaving aside the fact that I agree with Konstantin about the pure<br>
futility of using 8K RSA keys (but, well, if you're asking from<br>
the standpoint of "this is something that somebody who wants to use<br>
my program at some point in the future may want"... but even from<br>
that standpoint, there may also be people who build their own<br>
versions of cryptography tools with even crazier limits, so even<br>
8K might not be enough)...<br>
<br>
...so leaving all that aside, when you speak of field lengths,<br>
you do realize, don't you, that the raw key material is only<br>
a part of even the information that is stored in the keyring,<br>
not to mention the information that is exported as a certificate<br>
(what most people think of when they say "my public key")?<br>
There are user IDs, there are self-signatures, there are<br>
signatures from other partied that let you actually trust<br>
the key... and most of these do not really have a fixed<br>
count, limit, or length. Then there is the export format,<br>
the fact that if you want to transmit the key and certificate<br>
through a text medium, you'll have to encode it and make it<br>
even larger...<br>
<br>
G'luck,<br>
Peter<br>
<br>
-- <br>
Peter Pentchev <a href="mailto:roam@ringlet.net" target="_blank" rel="noreferrer">roam@ringlet.net</a> <a href="mailto:roam@debian.org" target="_blank" rel="noreferrer">roam@debian.org</a> <a href="mailto:pp@storpool.com" target="_blank" rel="noreferrer">pp@storpool.com</a><br>
PGP key: <a href="http://people.FreeBSD.org/~roam/roam.key.asc" rel="noreferrer noreferrer" target="_blank">http://people.FreeBSD.org/~roam/roam.key.asc</a><br>
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13<br>
</blockquote></div></div></div>