@sozialwelten It's 2025 now, and there are no tangible results.

@raucao It is also not a part of the official Mastodon Roadmap even though there are some open issues in the GitHub repository concerning E2EE.

I personally hope that it will get integrated into ActivityPub and/or Mastodon but for 2026 and 2027 I do not see any signs that there is anything remotely close to being published.

#E2EE #Issue​s #Github: https://github.com/mastodon/mastodon/issues?q=is%3Aissue%20state%3Aopen%20e2ee
#Mastodon #Public #Roadmap: https://joinmastodon.org/roadmap

@koteisaev @sozialwelten There is zero progress in that, just a few people discussing what anyone interested in E2EE already knows.

@koteisaev @sozialwelten FWIW, since Nostr identities are based on key pairs by design, and its developers care a bit more about privacy, E2EE DMs are already being tested via an MLS-based protocol there:

https://github.com/marmot-protocol/marmot

I think it's a shame that none of the large AP implementers are prioritizing this, because without user-owned keys, not just are DMs unencrypted, but there can be no true user sovereignty and account portability on the fediverse.

@lain @sozialwelten @koteisaev Yes.

@raucao @lain @sozialwelten @koteisaev FWIW, encryption with user-owned keys is on my roadmap. I don't want to start with MLS, though, it's too complex. The first prototype will likely encrypt messages with user's identity key, as described in https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md

@silverpill @lain @sozialwelten @koteisaev That could be the first step for anyone. Still better than sending unencrypted DMs around.

@sozialwelten@ifwo.eu I apologize if my point of view may seem conservative and narrow-minded... but in my opinion, pushing for the integration of encrypted messaging into the Fediverse is not advisable. I believe the best solution is that of the Lemmy developers, who have created a button that allows two users with a Matrix account to communicate via software designed for secure communications.

@raucao @silverpill @lain @sozialwelten @koteisaev the problem is not e2ee in itself. It's all the consequences: key management ux nightmare, no spam prevention from servers, no csam filter on servers, no search in server (client must download everything to index and search locally, good luck with mobile). I don't see a world where we have both e2ee and good usability

@silverpill @raucao @lain @sozialwelten @koteisaev

As a note, FEP-0806 is overly simplistic in that it has no forward secrecy.

As an easy improvement, if the sender also generates a per-message ephemeral X25519 keypair, you can do static-static + static-ephemeral KEX and get imperfect forward secrecy (no additional round trips required).

@greyarea @raucao @lain @sozialwelten @koteisaev Thank you for the advice. I need to start with something simple in order to learn how cryptography works. Then it will be replaced with a more secure scheme.

From what I learned so far, the core principle is pretty much the same in all modern encryption schemes, they differ in how shared symmetric key is generated. Is that correct?

@silverpill @raucao @lain @sozialwelten @koteisaev

Sorry for the delayed response, but yes.

The naive approach would be:

- Convert both party's Ed25519 keys to X25519 keys
- ECDH(Sender static, Recipient static) -> k
- HKDF(k) -> Shared secret

The problem with this approach is that, if either side's private key gets compromised, all historical traffic is trivially decryptable. (Static-Static ECDH)

Perfect forward secrecy (compromise of either key does not give attacker the ability to read past messages) requires at least one extra round trip, which is not great in this setting.

The tweak I suggested is:

- Convert both party's Ed25519 keys to X25519 keys
- Sender generates a ephemeral (throw away) X25519 key
- ECDH(Sender static, Recipient static) -> k_1
- ECDH(Sender ephemeral, Recipient static) -> k_2
- HKDF(k_1 | k_2) -> Shared secret
- Sender discards the ephemeral key

With this improvement, sender long term key compromise does not allow decryption of past traffic, because the ephemeral keypair is long gone into the void (one-way forward secrecy, Static-Static + Ephemeral-Static ECDH).

Note: While the theoretical safety of reusing a Ed25519 key for also doing X25519 was an open question, there are proofs that it is safe.

@greyarea Hi, I tried to implement the mechanism described in the FEP and decided to use HPKE (RFC-9180). What do you think of it?

HPKE seems to address the issue you pointed out back then: https://www.rfc-editor.org/rfc/rfc9180.html#name-forward-secrecy.

At least if used properly. The library I am using hard-codes "info" and "aad" strings: https://github.com/rustonbsd/ed25519-dalek-hpke/blob/27b010a9ae25ba4ce051510eadfd103a179dd715/src/lib.rs#L98-L104

Anyway, here's an updated FEP: https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md

@raucao @lain @sozialwelten @koteisaev

@silverpill @raucao @lain @sozialwelten @koteisaev

HPKE has the benefit of being standardized, and imperfect forward secrecy is the best you can do with 0-RTT (which probably fits the fediverse model better).

Just be very careful about the "use correctly" and it's "fine". I'm partial to Noise (https://noiseprotocol.org/) for these sort of use cases because it has less foot+guns and there's more flexibility, but I wouldn't freak out or scream if I saw HPKE in use.

As a side note, it is indeed safe to convert ed25519 keys to X25519 keys assuming a common sense step is taken when using the latter (https://eprint.iacr.org/2021/509).

@greyarea @raucao @lain @sozialwelten @koteisaev Is there anything built on top of Noise for group messaging?

As far as I can tell, HPKE is used in MLS

@silverpill @raucao @lain @sozialwelten @koteisaev

WhatsApp.

It's biggest claim to fame is non-group messaging (WireGuard), and the fact that the designer based it on the Signal wire protocol design (same person). The latter research that adds concrete security proofs is an added bonus, as well as decent library availability.

But, there's only so many ways to do NIKE (Non-Interactive Key Exchange), and the IETF/IRTF has a preference for reusing their own standards.

TLDR: Noise over HPKE is a personal preference, I think it's harder to blow your foot off with Noise and it's easier to implement (having done multiple Noise impls, and dealt with HPKE more than I should), but honestly either is a reasonable choice, and if you want something more standardized, HPKE is reasonable.

@greyarea I added HPKE algorithm parameters to the FEP:

Cookie monster!

(codeberg.org)

KEM: DHKEM(X25519, HKDF-SHA256)
AEAD: ChaCha20Poly1305
KDF: HKDF-SHA256
"info" string: fep-0806-info
"aad" string: fep-0806-aad

Does it look right?

KEM/AEAD/KDF choices are not my preferences, I just copied them from another HPKE+ed25519 implementation.

@silverpill

The primitive choices are sensible.

The "aad" is sent in the clear (or just public as it is now) so you could do something like "fep-0806-aad" | ':' | <id> | ':' | <actor> |':' | <to>. If the proof covers all of that then it's not strictly needed, but it's cheap paranoia.

I was going to say add version info to the labels, but fep0806:cipherAlgorithm covers that.