Maximum keypair length...

[Ángel]

On 2020-05-08 at 13:27 -0400, Barry Smith via Gnupg-users wrote:
> 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. :)


Sorry, but your scenario is really weird, to the point I suspect you are
not understanding/taking things into account properly.

What do you try to achieve? What's your threat model?

If everyone involved will have both the public and secret daily keys, I
don't see the need for using public cryptography. Just generate all
those daily keys¹ as a random 128 bit passphrase each and use a
symmetric cipher such as AES.²


In fact, if everyone receives all the keys at once, someone that got
hold of one daily client by compromised a client, would get hold of all
of them. So your daily keys add about nothing here, and you can use a
single keypair or a single symmetric key.
A neat way to still change keys daily, rather than using that symmetric
directly, would be to use a HMAC of that key with the given day.
But really, an attacker won't recover your key through cryptanalysis,³
malware, wrenches and people's stupidity are more important threats.

A part when key rotation would help would be when people joins and parts
such group. A new member only needs to receive the keys from now on, so
if everyone used a different key each day, even if the new member
somehow had the ciphertext for the day previous to joining the private
group, he wouldn't be able to read it.

However, if in the above process we changed:
  Daily_key[today] = HMAC(<initial chat key>, Today)
  Encryption_key = Daily_key[today]
with something like
  Daily_key[today] = HMAC(first 128 bits of Daily_key[yesterday], Today)
  Encryption_key = last 128 bits of Daily_key[today]

then we also get that property of protecting old messages from an
attacker with the key for the current day.

This allows the app to daily forget the keys of the day before
yesterday, so it cannot be obtained by an attacker that compromised the
device. 


In both cases, when people leaves the group you will need to rekey,
distributing new key(s) to everyone.



As for your usage of an ics file to store gpg keys, they have not-before
and not-after dates, so just distributing keys (or subkeys) with those
values properly set would have any implementation do the right thing of
picking the correct key.
However, there is little reason to create such keypairs, per above.

A more usual approach if you were using public key cryptography would be
to use a key per user and simply interchange pgp messages. Have a look
at how deltachat implements that.

Also review the Signal protocol,⁴ which is much more complete (and
complex) than everything layered out here.

Cheers



¹ Initially you mentioned 427 keys, but later mentioned they were "less
than 33 keys"
² You still need to properly use a block cipher mode such as GCM, don't
reuse iv, etc. You may use pgp for the encryption, but you would not be
using gpg keys.
³ if everything is implemented properly
⁴ https://en.wikipedia.org/wiki/Signal_Protocol