this post was submitted on 15 Jul 2026
84 points (95.7% liked)
Technology
87550 readers
3264 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Put it in their profile. Seriously that's it. You can use a profile metadata field if you want to be formal about it.
Why would you need a history of what keys were whose?
Your instance admin subtitutes the public key in your profile with one they control.
How do you stop this?
Like, half the point of E2EE for DMs is to prevent instance admins from seeing what your messages say. The other half is to prevent instance admins from being able to surrender anything useful to government subpoenas.
As long as the admin doesn't possess the private key, that solution still prevents the latter issue. If the admin swaps out your public key for one they control, they could technically impersonate you and read messages after the swap, but not read any messages from before. The user would be unable to use E2EE as soon as the key is swapped, so the only real issue here is impersonation.
An admin could theoretically take over a user's account today, so there's not really a new vulnerability here. And with E2EE, there'd be a big clue about something funky happening with the public key changing.
EDIT: Oh.
That seems... strange? Not sure why that approach was chosen.
How much do you know about cryptography?
I've written tons about why this approach was taken, but it might be inaccessible to someone with limited knowledge of modern cryptography protocol design. (Authenticated encryption, forward secrecy, context commitment, etc.)
This was my earliest blog post on the topic, if you want a place to start.
I'd describe myself as a relatively knowledgeable layman. Essentially I know enough to use it effectively in a sysadmin/dbadmin capacity, but not got a good grasp of the underlying math.
Thank you, I'll take you up on that.
The biggest unsolved problem in public key cryptography is knowing that a public key belongs to a particular individual. Making sure an attacker hasn't swapped out keys or is impersonating you is a problem.with a non trivial solution