- cross-posted to:
- fediverse
- cross-posted to:
- fediverse
i should stress that no development has been made to this since last month and the only recent development was the sole contributor suggesting the idea to the official ActivityPub repo last week.
the contributor proposed sending an E2EE message as follows, using PGP keys that are stored with password encryption on the instance's server:
- It requests the recipents public key
- If there is a recipent public key, it sends the recipents public key to the sender
- If there is a recipient public key, it encrypts the message
- If there is no recipient public key, it will warn the user that this message will send unencrypted and the user can reject sending the message or continue sending the message with encryption.
- The message is sent to the user
currently, fediverse services just use existing E2EE services (Matrix, XAMPP, etc.) and while the demand isn't big i think it would be really convenient. especially as a part of ActivityPub, E2EE messages would work over different fedi services to any fedi account, as opposed to separate, incompatible implementations maintained by each fedi service.
what do you guys think about this idea? cool or no?
edit: btw if you don't know, "private" messaging on fediverse is equivalent to mentioned-only posting, meaning the instance admins can read them as plaintext. this is why Lemmy has a disclaimer warning that your messages aren't private, has a Matrix account field on your profile to securely message with and why virtually no fedi services have tried implementing E2EE encryption
You must log in or register to comment.
How do you ensure the public key being used is the correct one? Server could get hacked or could get replaced when server requesting from the activity pub federated server. Worse than unencrypted (with everyone knowing this) is unreliable encrypted with everyone thinking it’s working as expected.
I think using activity pub as a public key exchange would be good, but it can’t be half assed.
Yeah what would ultimately be the benefit, because there's no way this is going to be so secure and foolproof that it could be recommended for things that should actually be encrypted. Doesn't seem like it's worth the effort to add something like that to a social media website unless there's some existing system they can implement. It makes a lot more sense for messaging clients like Signal.
good point and i'm pretty sure that was the reason why it wasn't initially included in ActivityPub or virtually any other fedi service. it would be convenient to have secure messaging as a future and it would be interesting to emulate E2EE email services especially as ActivityPub already works similar to SMTP (email protocol)
generally, hacks that manipulate public keys are mitigated by the fact that they aren't compatible with already-existing signatures and signed messages as well as the corresponding private key stored on the user's device. it's the same way that expired/wrong certificates on HTTPS websites prevent the website from being accessed in the case that there is an attack (key manipulation, man-in-the-middle attack).
if a signature was also stored on the user's device, then a manipulated public or private key could be verified every time private messages are created or accessed, appending to an error log (useful for identifying a server breach) and requiring a new PGP public-private key pair to send future private messages.
I think E2EE would be a great addition -- and certainly a necessary one for proper DM support -- but what I would really love to see is a version where the instance can act like a certificate authority in a SSL/TLS-like trust chain, so that each user could publish and revoke keys for different purposes. Then I might have separate keys for different groups or individual members, kind of like Google+ (remember that?) used to have "circles" and now FB has Friend List or X/Twitter has Circles.
great idea! definitely consider commenting your idea on the GitHub issue. plus it would prevent @notfromhere@lemmy.ml's problem of the public key possibly being changed by being able to verify that the keys don't match.