Re: End-to-end Encrypted Messaging in ActivityPub

On Sat, May 20, 2023 at 11:23 AM Evan Prodromou <evan@prodromou.name> wrote:

>
> Synching keys between clients happens out of band. I think the typical UI
> is using a QR code.
>

PKI and key exchange, whee. You're right on all of this! Also there's also
a new hotness, key transparency, that avoids this manual user-facing step
that people often skip, and thus improves both usability and security.

https://github.com/google/keytransparency/#readme
https://engineering.fb.com/2023/04/13/security/whatsapp-key-transparency/
https://security.googleblog.com/2017/01/security-through-transparency.html



>
> Evan
>
> On May 20, 2023 00:17, Benjamin Goering <ben@bengo.co> wrote:
>
> Evan, I like the approach you illustrate using as2:mediaType:
> multipart/encryption + as2:content.
> I’ll have to read a bit about existing multipart/encryption specs.
>
> One thing that’s not quite clear to me from your proposal is what you have
> in mind for the encryption key that would be used? And how readers would
> get it?
> I think a hybrid encryption scheme would probably make the most sense in
> 1-to-many broadcast, where the encryption is only done once with a
> symmetric key, but then the symmetric key may itself be asymmetrically
> encrypted once for each authorized audience member. Then if a reader
> encounters an encrypted as2:content, and they don’t already have a key
> identified by the encrypted blob envelope, maybe then the reader could
> request the key by key-id explicitly from the original author
> (as2:attributedTo).
> I don’t these details are critical to decide now. It’s useful just to
> specify how encrypted blobs can be included in as2, but that alone seems
> insufficient to guarantee interoperability.
>
> Another solution that might be worth considering is using JWE as the media
> type, and including JWE as the value of the as2:content property.
> https://en.wikipedia.org/wiki/JSON_Web_Encryption
>
> One of the benefits over multipart/encryption, I think, seems to be that
> JWE might be more straightforward to decrypt in the browser (e.g. using
> globalThis.atop and globalThis.JSON.parse) than the multipart/encrypted
> media type. IMO it’s worth drafting an extension for at least these two and
> seeing what people decide to adopt over time (i.e. specifying a convention
> that is already a valid use of the protocols).
>
> Will keep thinking about this, especially if there might be a more
> serialization-independent way, or a good way of allowing for this use case
> with the encryption happening at another layer.
> e.g.
> https://www.researchgate.net/publication/317177393_Self-Enforcing_Access_Control_for_Encrypted_RDF
> or https://datatracker.ietf.org/wg/mls/about/
>
> It’s also worth being familiar with DIDComm, which has been designed for
> e2ee from the start. https://identity.foundation/didcomm-messaging/spec/ (it
> uses JWE)
> I’m still assessing didcomm, which is a big composition of things and
> under DIF not w3c.
> But did-core is w3c, and I’d really like to cooperate with the DID
> ecosystem (and e.g. the w3c credentials community group) for anything about
> cryptography.
>
>
>
> On May 19, 2023, at 07:25, Evan Prodromou <evan@prodromou.name> wrote:
>
> I published a blog post about an architecture for end-to-end encrypted
> messaging in ActivityPub:
>
> https://evanp.me/2023/05/19/end-to-end-encrypted-messages-over-activitypub/
>
> One option for this group is to publish Note documents. I think developing
> a standard mechanism for E2EE with multiple implementations could be a huge
> benefit for social web. I’d be happy to participate in such a subgroup!
>
> Evan
>
>
>

-- 
https://snarfed.org/