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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
