Re: End-to-end Encrypted Messaging in ActivityPub

It is good that Ben reminds us that the problem of e2ee is much more
difficult than most expect. Trivially, it seems that once you've got a
key-pair, you can just start encrypting stuff with a few lines of code and
a good library. The reality is very different and only now appreciated by a
very small number of people who are deeply steeped in the obscure realms of
cryptography and security. Even though I've been working, on and off, with
cryptographic methods since the late 1980's (i.e. over 30 years), I've
often found protocols or specs that appeared to me to be well thought out,
only to later discover that someone much more expert than I has dismissed
the described methods as dangerous, ineffective, or whatever.

Given that this problem is so hard, I'd like to suggest that an effort be
made not only to define useful, secure methods, but also to ensure that
there is a good and easily accessible explanation for why the methods were
chosen over alternatives. In essence, I'm suggesting that effort be put
into writing what in some OSI Standards efforts we called a standard's
"rationale." Yes, I do realize that if the issues are debated on mailing
lists, one can always dig through those lists to elucidate the history
behind the standard's dictates, however, I think few are likely to do that
work. It would be better to attempt to maintain a discipline that requires
that a detailed rationale be provided before any method is incorporated
into the standard. In essence, one should explain "why" before documenting
the specifics of "what" or "how."

bob wyman



On Fri, May 19, 2023 at 11:31 PM Benjamin Goering <ben@bengo.co> wrote:

> soatak also started writing about this 6 months ago, and I thought it was
> a great contribution. There is also a repo to contribute to:
>
> https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/
> f
>
>
> On May 19, 2023, at 19:21, a <a@trwnh.com> wrote:
>
> 
> > We need simple PGP-style key exchange for DMs
>
> we could honestly jump straight to OMEMO-like schemes and have servers
> generate pre-keys for their actors. i don't think PGP-style is worth going
> for unless you want to be able to persistently verify authored activities
> after-the-fact, and don't mind (or perhaps want?) anyone with the key being
> able to decrypt your messages.
>
> aside from that: i'm personally not convinced that we "need" such
> complexity. maybe it would be "nice to have" a way to do stuff like this
> over activitypub, but i think before encrypted messaging there needs to be
> a way to do plaintext messaging. until then, people will continue to go
> out-of-band to a dedicated messaging app.
>
> my current thoughts/notes on "messaging over activitypub" are as follows:
>
> - `Create Note` alone can be confused for a "status" or any of the other
> myriad things a `Note` gets used for. pleroma / litepub at one point in
> 2019 developed the ChatMessage as a new type and they sent out `Create
> ChatMessage`; i think this is not exactly the right approach since it makes
> more sense to have `Message` as an IntransitiveActivity which represents a
> "message" instead of a "resource". this also eliminates the need for
> wrapping in a `Create`. such `Message` activities could be transient if
> desired, or they could be persistent if given an `id`. (alternatively, if
> `context` was understood, you could have an explicit "messaging context"
> representing the room or conversation.)
>
> - the other thing we'd want to heavily look into and think about is
> metadata encryption. if we just encrypt, sign, attest, verify, etc. the
> content, then that's surely simpler, but it is also surely far less useful
> in many cases. otherwise, we could have had `content_sig` or something
> similar years ago to cryptographically work with the `content` and no other
> properties. i am reminded somewhat of diaspora*'s approach to this, which
> was to have a "magic envelope"
> https://diaspora.github.io/diaspora_federation/federation/magicsig.html
> that would encode the entirety of the "message" and then sign that encoded
> string. we could do something similar by having some dedicated Envelope
> activity type serve as this "envelope" which might contain `summary` and
> `content` as proposed above by Evan's blog post. i haven't fully considered
> the exact details, but i think at minimum you would have to leak the
> `actor` if nothing else. (this is because of the requirement to use
> activities to avoid the wrap-in-Create behavior. addressing could be hidden
> by use of bto/bcc instead of to/cc.)
>
>