GPG signature renewal vs new key
Hello,
When looking at the archlinux gpg keyring, I notice that when GPG keys expire, TU's regenerate a new key instead of renewing it.
Why do they regenerate a new key instead of renewing, is it the same reason we put expire dates on our TLS certificates (for security).
Is it bad to just renew your key without regenerating it?
Thanks,
On 1/21/23 15:24, Polarian wrote:
Hello,
When looking at the archlinux gpg keyring, I notice that when GPG keys expire, TU's regenerate a new key instead of renewing it.
Why do they regenerate a new key instead of renewing, is it the same reason we put expire dates on our TLS certificates (for security).
Is it bad to just renew your key without regenerating it?
Thanks,
Hi Polarian,
There are a lot of packagers that renew expiry on their keys frequently. We lately just had a lot of new keys with stronger binding signatures as they were using sha1 as well as use more modern RSA-4096 or ed25519 alongside with enforcement of using @archlinux.org UIDs. That may be the real reason you are observing new keys in the keyring.
In terms of security, GPG expiry itself has no security properties and it's primary purpose is to let an identity mark itself as outdated automatically in case one or the other way access to the private key material has been lost/destroyed. Otherwise an old unusable key may keep lingering around on keyservers for all eternity and one may not easily know which is the active one.
Revocations are the only security property in that regard, as they can't be undone once published/received contrary to expiry dates that can always be updated if a third-party gains access to the private key even if keys expired.
In regard to your comparison about renewing keys, there is certainly some truth in it. The longer a key exist the bigger the theoretical window of opportunity for a stolen/broken key material to remain valid while being misused. In general that's also where single purpose keys come in handy when they are combined with transparency logs and proper monitoring as that would be the safest way to make any statement about active key misuse. This would definitively be the future that Arch packaging keyring aims for, but it will take time on various layers until we are there.
Sincerely, Levente
Hello,
Sorry for the late response, I forgot to reply after sending the email.
There are a lot of packagers that renew expiry on their keys frequently. We lately just had a lot of new keys with stronger binding signatures as they were using sha1 as well as use more modern RSA-4096 or ed25519 alongside with enforcement of using @archlinux.org UIDs. That may be the real reason you are observing new keys in the keyring.
In terms of security, GPG expiry itself has no security properties and it's primary purpose is to let an identity mark itself as outdated automatically in case one or the other way access to the private key material has been lost/destroyed. Otherwise an old unusable key may keep lingering around on keyservers for all eternity and one may not easily know which is the active one.
Revocations are the only security property in that regard, as they can't be undone once published/received contrary to expiry dates that can always be updated if a third-party gains access to the private key even if keys expired.
In regard to your comparison about renewing keys, there is certainly some truth in it. The longer a key exist the bigger the theoretical window of opportunity for a stolen/broken key material to remain valid while being misused. In general that's also where single purpose keys come in handy when they are combined with transparency logs and proper monitoring as that would be the safest way to make any statement about active key misuse. This would definitively be the future that Arch packaging keyring aims for, but it will take time on various layers until we are there.
When I created my GPG key, I forgot to set it to RSA 4096 at the time, so my key is RSA 3072, which is not as secure. Do you recommend changing over to a more secure algorithm such as ed25519 (elliptical curve) within the following year?
Also as a follow up question, the reason I never changed my key is I far that if I do it would cause major issues, all the commits signed with my former key will become unverified, I will need to reconfigure all my clients to use my new key, and people would need to import my new key to have the correct signature on my emails.
It seems a lot more hassle than it is worth, especially how RSA has still (thankfully) not yet been broken, but anything less than 2048 bits is insecure, and also going above 2048 bits is extremely slow, increasing the overhead.
Thanks,
participants (2)
-
Levente Polyak
-
Polarian