(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.
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").
> 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.
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.
>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.
You can still do that with a .dmg, for example. I've done it, it works more or less like a zip.
But even if that was somehow unreasonable or undesired, you can use Filippo's age for that. PGP has no use case that isn't done better by some other tool, with the possible exception of "cosplay as a leet haxor"
I strongly agree with you, but I have no confidence in my country's current elected representatives to ever do anything good, so our hands are tied until we vote them out.
The whole point of end-to-end encryption is that you shouldn't have to.
The entire point of Sealed Sender and their use of zero-knowledge proofs for group membership is so the server doesn't know who's talking to who, so they can't even selectively censor messages from one person.
Interesting. Who distributes my keys from me to my recipient? Is it someone in the middle? You can see where I'm going with this.
Signal's way to validate that a session isn't man-in-the-middle'd is the same as XMPP: You have to validate the session's fingerprint in real life, or over another secure channel, by scanning each other's QR code, a procedure we'll refer to as "the QR thing".
Over more than five years of Signal usage, I personally did this exactly twice.
Now, we can start to imagine the typical Signal user.
Either we consider that I'm a minority and at least the vast majority of people do "the QR thing", so most/all sessions are secure from any man-in-the-meddling.
But then, you present the argument that XMPP is insecure because it can send plaintext. So this imaginary Signal user would be careful and privacy-inclined enough to use "the QR thing", but too careless to keep OMEMO on his XMPP client (where it's on by default in the vast majority) !?
I can't imagine this user. I fail.
The other way to reason about this is that, just like me, no one does "the QR thing". The vast majority of sessions are not protected against an MITM. Note that "the QR thing" is identical on XMPP, so all previous criticisms apply, except for a key difference...
On XMPP, servers are small. Trust is diluted, and in a lot of cases, you know personally your administrator, if you're not tech-oriented, because your administrator is the guy who told you about it.
Even when it doesn't matter, the server does matter a bit, eh?
> Signal's way to validate that a session isn't man-in-the-middle'd is the same as XMPP: You have to validate the session's fingerprint in real life, or over another secure channel, by scanning each other's QR code, a procedure we'll refer to as "the QR thing".
Tell me you didn't read the article, without telling me you didn't read the article.
They're adding Key Transparency to keep themselves honest. Their specific implementation today (which is probably not final) was one of the final parts I reviewed:
If you're going to talk about this with profound ignorance, it's probably wisest to not do so while responding to a blog post that significantly spent time on the piece that debunks your whole premise.
Yes, and furthermore, there's already built-in support for ledger monitors to ensure the honest and integrity of their log.
The whole point of Key Transparency is to keep the server honest. Publishing may be centralized, but verification is decentralized. This is literally a problem space I'm working in right now! https://soatok.blog/category/technology/open-source/fedivers...
> Repeat after me: The server matters. A lot. Even if you don't want it to.
The only thing the server can influence is availability:
1. Whether or not you can participate in the network to begin with (which is mostly to prevent spam, and is the only component you still need a phone number for today)
2. Deciding whether messages are delivered or not, to everyone.
Signal can't selectively censor users, they can only stop the operation of the entire service at once. Sealed Sender and zkgroup address this.
With key transparency, Signal couldn't even mislead users about which public keys belong to each user if they wanted to.
There is no other powers, besides basic availability, that the server needs to provide.
Just because you're used to technologies where the server has more power than the clients, and where some clients can continue to use OMEMO 0.3.0 in 2025 while the rest of the ecosystem is on 0.8.3, doesn't mean your experience is necessarily relevant here.
As noted elsewhere, Signal has offered reproducible builds since March 2016. If you care that much about about client security, why not check that yourself and blow the whistle if the binaries mismatch?
Thank you for your work and thanks for your immense patience answering mostly-already-addressed concerns of someone who has not bothered to even read the article. It's bad form; noble of you to answer (and hopefully useful for others / posterity).
_edit_ spent some time on your blog (turns out I've done that before - recognised style as well as furry universe / ontology; nice feeling to return). Reading reasons for disliking AES-GCM (always liked this simplicity + auth-baked-in AEAD approach as a dev/architect/user of applied crypto)...
If you see this _edit_ - do you use any specific tools to generate various sequence / flow diagrams? anything besides mermaid (+ draw.io, I somehow never got rid of using this one in times of urgent need...)? Thanks :)
Wasn't downvoting for the questions, but started downvoting these comments of yours because of your attitude + expectation that OP will answer questions that have in various ways already been addressed if you read the article.
I believe it is bad form / in bad taste to arrogantly presume your questions and points about server trust (and etc.) are unique, not addressed, and create new challenges; without first reading the article which is the bare minimum required for this, IMHO.
Btw, depending on your threat model you may want to validate pubkeys / established session key / etc. using other side channels regardless of software, protocol and medium used.
> The issue with security researchers, as much as I admire them, is that their main focus is on breaking things and then berating people for having done it wrong.
> Great, but what should they have done instead? Decided which of the 10 existing solutions is the correct one, with 9 being obvious crap if you ask any security researcher?
There's 10 existing solutions? What is your exact problem space, then?
I'm also working in all of my spare time on designing a solution to one of the hard problems with cryptographic tooling, as I alluded to in the blog post.
> How should the user know? And typically none of the existing solutions matched the use case exactly. Now what?
First, describe your use case in as much detail as possible. The closer you can get to the platonic ideal of a system architecture doc with a formal threat model, the better, but even a list of user stories helps.
Then, talk to a cryptography expert.
We don't keep the list of experts close to our chest: Any IACR-affiliated conference hosts several of them. We talk to each other! If we're not familiar with your specific technology, there's bound to be someone who is.
This isn't presently a problem you can just ask a search engine or generative AI model and get the correct and secure answer for your exact use case 100% of the time with no human involvement.
Finding a trusted expert in this field is pretty easy, and most cryptography experts are humble enough to admit when something is out of their depth.
And if you're out of better options, this sort of high-level guidance is something I do offer in a timeboxed setting (up to one hour) for a flat rate: https://soatok.com/critiques
> I've literally blogged about tool recommendations before
Do you happen to know of a similar resource applicable to common HN deployment scenarios, like regular client-server auth?
For example, in your Beyond Bcrypt blog post[0] you seem to propose hand-writing a wrapper around bcrypt as the best option for regular password hashing. Are there any vetted cross-language libraries which take care of this? If one isn't available, should I risk writing my own wrapper, or stick with your proposed scrypt/argon2 parameters[1] instead? Should I perhaps be using some kind of PAKE to authenticate users?
The internet is filled with terrible advice ("hash passwords, you can use md5"), outdated advice ("hash passwords, use SHA with a salt"), and incomplete advice ("just use bcrypt") - followed up by people telling you what not to do ("don't use bcrypt - it suffers from truncation and opens you up to DDOS"). But to me as an average programmer, that just leave behind a huge void. Where are the well-vetted batteries-included solutions I can just deploy without having to worry about it?
Your tool recommendations are actively harmful and dangerous in places.
You whole-heartedly recommend sigstore, a trusted-third-party system which plainly trusts the auth flows of the likes of Google or Github. It is basically a signature by OpenID-Login. This is no better than just viewing everything from github.com/someuser as trusted. The danger of key theft is replaced by the far higher danger of account theft, password loss and the usual numerous auth-flow problems with OpenID.
Why should I take those recommendations seriously?
> I don't see many "cryptography experts" putting effort into improving developer documentation resources for libraries.
This isn't a "documentation resources for libraries" problem. It's a what libraries get bundled into the "crypto" module for your programming language problem, and that's largely a political decision rather than a technical one.
For example: Node's crypto module will always be a thin wrapper around OpenSSL, due to backwards compatibility. I cannot change that reality. There will always be a way to shoot yourself in the foot with Node.js's crypto module, and that is what most developers will reach for.
Even if I introduce new APIs for Node crypto and update the official docs to recommend the newer, safer ways of doing things, I won't be able to update the long tail of Stack Overflow answers with 10+ years of incumbency and hundreds of upvotes. This was tried years ago in the PHP community, and you still find bad PHP code everywhere.
Updating the developer documentation only serves to blame the poor user when they fuck up, so you can dismiss their pain with "RTFM".
> But plenty of them ranting and acting butthurt that developers aren't educated enough to use the primitives. The same crypto experts will also release these libraries and then cry that people use them.
I have never contributed a line of code to OpenSSL. You do not hear Eric A Young "ranting and acting butthurt". What empirical evidence do you have for this assertion?
A single Public Key Directory will serve many hosts. (You can further add replication and cross-directory checkpointing between directories, to ensure the whole network is transparent, but that's not our concern right now.)
If a host decides to misbehave, there's an independently hosted record of every change to the state machine that maps Actor IDs to public keys. This state machine is backed by a Merkle tree, which includes a proof of inclusion for every change to its state, thereby making it an append-only ledger.
In my design, you don't have to trust the hosts' admins to behave, because the directory keeps them honest.
You also don't have to trust as single directory to behave, since its primary purpose is to be transparent and independently auditable.
If a user wants to revoke their key, they can, but it's an additional protocol message appended to the directory's transparency log.
If a user loses all their secret keys, one of two things can happen:
1. Their instance admin issues a BurnDown, which allows the user to enroll a new public key as if they were a new user.
2. If the user has issued a Fireproof message, the instance admin cannot issue a BurnDown, and the user is locked out of the protocol. This is a trade-off.
Users can move hosts. Users can publish auxiliary data (e.g., SSH public keys), if the extension for that key type is defined and enabled by the directory. Even an attacker with root access to the host cannot arbitrarily or selectively replace a user's public key with their own. With your suggestion, this substitution is trivial.
And that's basically how the system works. But that's not the focus of this blog post.
This blog post is how to solve the seemingly incompatible design goals of:
1. Offer userbase consistency verification for users' public keys.
2. Don't cryptographically inhibit an EU citizen's rights under Article 17 of the GDPR.
3. Don't introduce backdoors to the transparency log that allow them to perform the same trivial attack that your suggestion enables.
Totally unrelated to the thread, just a comment on something I noticed: You seem to be posting from 2 different accounts: soatok and some_furry. Dunno if that’s on purpose, but in the off chance that it is not: Now you know.
Love you blog, it’s nice to read something written by an actual human being nowadays. I keep several of you articles bookmarked for reference.
> You seem to be posting from 2 different accounts: soatok and some_furry. Dunno if that’s on purpose, but in the off chance that it is not: Now you know.
When folks have interesting comments that warrant a response (or answer, if it contains a question), I very quickly stumble over HN's rate limit. Using this second account works around it.
As a rule, I only use this fallback account when my main (some_furry) is unable to respond to someone's questions.
If a user has to call into your keyserver to get a key before they can start a conversation with a new friend, as you're the sole authority who can decrypt the Merkle tree entries - does that introduce any problems?
And how will you authenticate shredding requests? Does that just happen out-of-band?
> If a user has to call into your keyserver to get a key before they can start a conversation with a new friend, as you're the sole authority who can decrypt the Merkle tree entries - does that introduce any problems?
It would, but they're addressed by the total design.
> And how will you authenticate shredding requests? Does that just happen out-of-band?
Essentially, yes, it's out-of-band. The actual shredding isn't part of the protocol.
The way I see it is, this only matters when the requestor's lawyers issue a takedown for their client's Personal Data (previously referred to erroneously as PII, though the distinction between the two jargony terms wasn't something I ever needed to care about).
If I didn't take the steps outlined in this blog post, the director's operator would be in a precarious legal situation.
But with this specification, the operator just queries their database for the in-scope records and deletes the stored key.
How that's actually implemented in software, and how the operator verifies that the legal notice for the takedown is authentic, aren't problems I have a readily available solution for. There may not even be a one-size-fits-all solution here.
As I've said, my goal isn't "GDPR Compliance". That's not a property I'm advertising. My goal is to create Key Transparency and a PKI without Authorities for the Fediverse.
I simply don't want to make it logistically impossible for someone else to deploy this in the EU.
> 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.