Encrypted Messages · Issue #449 · w3c/activitypub
github.com
Here is a simple way I would like to purpose implimenting E2EE messaging in ActivityPub. Simply by using OpenPGP. Every single account on activitypub will have a new field that is not visible to th...

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:

  1. It requests the recipents public key
  2. If there is a recipent public key, it sends the recipents public key to the sender
  3. If there is a recipient public key, it encrypts the message
  4. 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.
  5. 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

  • asante [comrade/them]@hexbear.netOPEnglish
    1·
    2 months ago

    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.