[some_furry]

Why is a keyring important to you?

Would "fetch a short-lived age public key" serve your use case? If so, then an age plugin that build atop the AuxData feature in my Fediverse Public Key Directory spec might be a solution. https://github.com/fedi-e2ee/public-key-directory-specificat...

But either way, you shouldn't have long-lived public keys used for confidentiality. It's a bad design to do that.

[johnisgood]

> you shouldn't have long-lived public keys used for confidentiality.

This statement is generic and misleading. Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine AND desired.

> Would "fetch a short-lived age public key" serve your use case?

Sadly no.

[soatok]

(This is some_furry, I'm currently rate-limited. I thought this warranted a reply, so I switched to this account to break past the limit for a single comment.)

> This statement is generic and misleading.

It may be generic, but it's not misleading.

> Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine.

What exactly do you mean by "long-lived"?

The "lifetime" of a key being years (for a long-lived backup) is less important than how many encryptions are performed with said key.

The thing you don't want is to encrypt 2^50 messages under the same key. Even if it's cryptographically safe to do that, any post-compromise key rotation will be a fucking nightmare.

The primary reason to use short-lived public keys is to limit the blast radius. Consider these two companies:

Alice Corp. uses the same public key for 30+ years.

Bob Ltd. uses a new public key for each quarter over the same time period.

Both parties might retain the secret key indefinitely, so that if Bob Ltd. needs to retrieve a backup from 22 years ago, they still can.

Now consider what happens if both of them lose their currently-in-use secret key due to a Heartbleed-style attack. Alice has 30 years of disaster recovery to contend with, while Bob only has up to 90 days.

Additionally, file encryption, backups, and archives typically use ephemeral symmetric keys at the bottom of the protocol. Even when a password-based key derivation function is used (and passwords are, for whatever reason, reused), the password hashing function usually has a random salt, thereby guaranteeing uniqueness.

The idea that "backups" magically mean "long-lived" keys are on the table, without nuance, is extremely misleading.

> > Would "fetch a short-lived age public key" serve your use case?

> Sadly no.

shrug Then, ultimately, there is no way to securely satisfy your use case.

[johnisgood]

You introduced "short-lived" vs "long-lived", not me. Long-lived as wall-clock time (months, years) is the default interpretation in this context.

The Alice / Bob comparison is asymmetric in a misleading way. You state Bob Ltd retains all private keys indefinitely. A Heartbleed-style attack on their key storage infrastructure still compromises 30 years of backups, not 90 days. Rotation only helps if only the current operational key is exposed, which is an optimistic threat model you did not specify.

Additionally, your symmetric key point actually supports what I said. If data is encrypted with ephemeral symmetric keys and the asymmetric key only wraps those, the long-lived asymmetric key's exposure does not enable bulk decryption without obtaining each wrapped key individually.

> "There is no way to securely satisfy your use case"

No need to be so dismissive. Personal backup encryption with a long-lived key, passphrase-protected private key, and offline storage is a legitimate threat model. Real-world systems validate this: SSH host keys, KMS master keys, and yes, even PGP, all use long-lived asymmetric keys for confidentiality in non-ephemeral contexts.

And to add to this, incidentally, age (the tool you mentioned) was designed with long-lived recipient keys as the expected use case. There is no built-in key rotation or expiry mechanism because the authors considered it unnecessary for file encryption. If long-lived keys for confidentiality were inherently problematic, age would be a flawed design (so you might want to take it up with them, too).

In any case, yeah, your point about high-fan-out keys with large blast radius is correct. That is different from "long-lived keys are bad for confidentiality" (see above with regarding to "age").

[maxtaco]

An intended use case for FOKS (https://foks.pub) is to allow long-lived durable shared secrets between users and teams with key rotation when needed.

[some_furry]

> The Alice / Bob comparison is asymmetric in a misleading way. You state Bob Ltd retains all private keys indefinitely. A Heartbleed-style attack on their key storage infrastructure still compromises 30 years of backups, not 90 days.

No. Having 30 years of secret keys at all is not the same of having 30 years of secret keys in memory.

[stackghost]

>Personal backup encryption with a long-lived key, passphrase-protected private key, and offline storage is a legitimate threat model

... If you're going to use a passphrase anyway why not just use a symmetric cipher?

In fact for file storage why not use an encrypted disk volume so you don't need to use PGP?

[johnisgood]

That was just me being goofy in that bit (and only that), but I hope the rest of my message went across. :)

> In fact for file storage why not use an encrypted disk volume so you don't need to use PGP?

Different threat models. Disk encryption (LUKS, VeraCrypt, plain dm-crypt) protects against physical theft. Once mounted, everything is plaintext to any process with access. File-level encryption protects files at rest and in transit: backups to untrusted storage, sharing with specific recipients, storing on systems you do not fully control. You cannot send someone a LUKS volume to decrypt one file, and backups of a mounted encrypted volume are plaintext unless you add another layer.

[stackghost]

>You cannot send someone a LUKS volume to decrypt one file, and backups of a mounted encrypted volume are plaintext unless you add another layer.

Veracrypt, and I'm sure others, allow you to do exactly this. You can create a disk image that lives in a file (like a .iso or .img) and mount/unmount it, share it, etc.

[deknos]

We need a keyring at a company. Because there's no other media for communicating, where you reach management and technical people in companies as well.

And we have massive issues due to the fact that the ongoing-decrying of "shut everything off" and the following non-improvement-without-an-alternative because we have to talk with people of other organizations (and every organization runs their own mailserver) and the only really common way of communication is Mail.

And when everyone has a GPG Key, you get.. what? an keyring.

You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?

the public keys are not that public, only known to the contenders, still, it's an issue and we have a keyring

[Natanael_L]

You need a private PKI, not keyring. They're subtly different - a PKI can handle key rotation, etc.

Yes there aren't a lot of good options for that. If you're using something like a Microsoft software stack with active directory or similar identity/account management then there's usually some PKI support in there to anchor to.

Across organisations, there's really very very few good solutions. GPG specifically is much too insecure when you need to receive messages from untrusted senders. There's basically S/MIME which have comparable security issues, then we have AD federation or Matrix.org with a server per org.

> You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?

How are you handling the keys? This is only true if user's protect their own keypairs with strong passwords / yubikey applet, etc.

[some_furry]

> We need a keyring at a company.

https://xyproblem.info

Look closely at the UX I'm proposing in https://github.com/fedi-e2ee/pkd-client-php?tab=readme-ov-fi...

Tell me why this won't work for your company.