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.

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.

If they won't pay for it, they can also kindly fuck off and not crawl my blog. Both are fine outcomes for me.

> Will the verification be automatic?

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?

> 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:

https://soatok.blog/signal-crypto-review-2025-part-7/

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.

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.

I wasn't present for the NIST crypto reading group, but I documented a lot of these in 2022, if you'd like a deeper dive into that problem space: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-...

> 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.

This is plain incorrect in my experience.

Recommended reading (addresses the motivations and ethics of security research): https://soatok.blog/2025/01/21/too-many-people-dont-value-th...

> 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've literally blogged about tool recommendations before: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

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.

https://soatok.blog/2024/06/06/towards-federated-key-transpa...

Is this not enough of an answer for you?

> 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 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?

Thanks, happy to help!

> 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?

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.

Thanks for the kind words.

I wrote a previous deep dive into database cryptography, which talks about things like searchable encryption (which may offset some of the relevant inefficiencies): https://soatok.blog/2023/03/01/database-cryptography-fur-the...

Happy hacking :3

> Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements?

I'm not sure the wording here is helpful.

Let's start with a simple diagram: https://github.com/fedi-e2ee/public-key-directory-specificat... (see the first one)

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.

> For sure more than a single-digit percentage of people have tried a Q&A bot by now.

Tried is doing a lot of heavy lifting. https://meow.social/@crumbcake/113156927685392932

> Shoot, Windows just updated to insert Copilot into users' machines, with the icon right next to the Windows button.

This goes back to my point about consent and opt-in vs opt-out.

> It can't not continue to grow.

"If we shove this down people's throats enough maybe their gag reflex will adapt."

> It's such an amazingly effective way to get information versus scouring through web pages.

The only reason I stopped using Google isn't to choose AI instead. It's because the obtrusive "AI Overview" pissed me off.

> The hype is around like content creation and AGI, which is a nothingburger.

Right, which is why TFA specifically talks about "Generative AI".

> Yes, that is absolutely what I meant.

> That doesn't mean that it operates at the specific level of bosons or the force of gravity, which is what I read your comment as suggesting.

This is a contradiction.

If something is as fundamental as bosons, then it operates at the same level as bosons. Otherwise, it's not as fundamental as bosons. It could be more fundamental, it could be less.

I gave the examples of tensegrity and fluid dynamics above. That they're not as fundamental as quantum fields doesn't make them any less real. They're just not as fundamental.

So which is it?

> It's been a pleasure conversing -- I sadly no longer have time to continue, but these are exactly the kinds of debates philosophers of consciousness have -- there's a lot to clarify and figure out! It's a fascinating field.

I understand. I'm leaving my response for anyone else who agrees with you to pick up should they choose.

> I didn't say that it belongs at the same level of abstraction, and no that isn't necessarily implied.

The definition of fundamental is, in this context, best compared with this one from Merriam Webster: "of or relating to essential structure, function, or facts" -- https://www.merriam-webster.com/dictionary/fundamental

When you compare things using "as", you're stating equivalence.

The statement "Conscious awareness appears to be a fundamental aspect of the universe -- as fundamental as the four known fundamental forces" states that consciousness is as relative to the essential structure as the four fundamental known forces.

The most literal meaning of what you said above is: Consciousness is as relative to the essential structure, function, or facts as the four known fundamental forces.

If that's not what you intended, then you're free to acknowledge that you misspoke, and to correct your previous statement with a clearer, more precise meaning.

But to say "and no that isn't necessarily implied" is wrong.

> Nobody said consciousness is best described at the subatomic level next to bosons.

Above:

> Conscious awareness appears to be a fundamental aspect of the universe -- as fundamental as the four known fundamental forces

If it's as fundamental as the four fundamental forces, then it belongs in the same level of abstraction. Fluid dynamics isn't as fundamental as quantum chromodynamics.

I found the statement that consciousness is as fundamental should be worthy of further examination. Hence, my inquiry.

> But philosophically, the fact that consciousness is going to be part of physics is self-evidently true. It's true by definition if you believe that consciousness interacts with the universe as described by physics -- for which the specific evidence is that we're having this conversation in the first place.

Okay, yes, but that's a very different notion than what was discussed above. Consciousness being purely physical is, I believe, the most likely explanation. It being as fundamental as neutrinos is not.

(My primary account is rate limited, so I'm posting my final comment in this thread from my alt.)

> And you haven't mentioned the moderation costs to Meta.

What about my comment obligates me, in any way, to mention that? It seems like an odd thing to demand.

What's going to happen is: the far-right pockets are ad-unfriendly (ad-adverse?), so they're out. But the far-left instances are anti-corporate, so they'll block Meta. What remains are heavily skewed towards the statist democrat types who are generally civil and well-mannered. I wouldn't expect the moderation burden to be too heavy from that crowd. The only significant moderation cost will be if Zucc abandons all sense and federates with instances that allow right-wing extremists. That would be an expensive blunder.

(Still stupidly rate-limited on my main account, so have to reply from this one. Dang it.)

> I always laugh when I see that "furry" is a category too choose server from on the official page.

> Too bad there is no "hentai" that would be the cherry on the cake.

It sounds like you think "furry" and "hentai" are congruent categories.

My understanding is that hentai is pornographic. Furry, conversely, is not. More information: https://soatok.blog/2021/04/02/the-furry-sexuality-blog-post

It does exactly what I've been describing!

They provide AE, not AEAD.

They feed an IV and ciphertext into HMAC. They don't feed additional authenticated data.

If someone followed Signal's example, they either wouldn't have AEAD, or they're likely to make the exact mistake described in the post I linked above.

I don't know how to be more helpful here. I've been only repeating myself.

AEAD modes let you bind a ciphertext to a context without increasing bandwidth. This is super important for database cryptography. Read more: https://soatok.blog/2023/03/01/database-cryptography-fur-the...

Whether "it's not AEAD" matters for an application depends on many factors. Signal doesn't need it.

I don't care about his opinions or takes, I care about the harm he inflicts by reinforcing the beliefs that undermine junior developers' confidence.

> His comment was a response to your post. Your post discouraged people from writing crypto, because they aren't qualified. This is where you were gatekeeping.

Re-read the post carefully. I included examples of people unwittingly trying to gatekeep me in the past.

The negative part of that post was about scammers and crackpots who, when confronted with constructive feedback about their designs, doubled down insisting they were smarter than their critics.

Being a neophyte doesn't make you a crackpot.

From the article:

> If you’re reading this blog post and feel like learning about cryptography and cryptanalysis and feel put off by the “don’t roll your own crypto” mantra, and its implied gatekeeping, I hope it’s clear by now who that phrase was mostly intended for and why.

(i.e. "NOT YOU" was the implication of that sentence)

The post in question is a lot of things, but it's not a gatekeeping piece.

For that matter, I also previously wrote this one to resist the tendency of gatekeeping in cryptography: https://soatok.blog/2020/06/10/how-to-learn-cryptography-as-...

I don't have a personal political agenda here.

I'd love for GNU cryptography to be better, but the first step in fixing problems is to acknowledge they exist in the first place.

GNUnet, GnuPG, etc. need to actually learn from modern cryptography projects like age and Signal, instead of doubling down in the name of ideology.

It's so good.

I've been meaning to write a GUI frontend (probably in Electron, but still) so that desktop users can experience its magic, but I keep putting it off.

Maybe this weekend? :)

> It's all best practices and hygine stuff. Which is fine, but hardly justfication for "Bad Cryptography".

Cryptographers have spent years trying to clean up the GNU cryptography ecosystem [1] [2].

[1] https://twitter.com/FiloSottile/status/1281055144659030016

[2] https://lists.gnupg.org/pipermail/gcrypt-devel/2015-November...