Separate from my proposal for key transparency for the Fediverse (which I’ve certainly blogged about a lot), the W3C has been working on building out end-to-end encryption (E2EE) for Activity…
As long as the admin doesn’t possess the private key, that solution still prevents the latter issue. If the admin swaps out your public key for one they control, they could technically impersonate you and read messages after the swap, but not read any messages from before. The user would be unable to use E2EE as soon as the key is swapped, so the only real issue here is impersonation.
An admin could theoretically take over a user’s account today, so there’s not really a new vulnerability here. And with E2EE, there’d be a big clue about something funky happening with the public key changing.
EDIT: Oh.
These aren’t encapsulation keys (a.k.a., asymmetric or “public key encryption” keys). Encapsulation keys belong to the MLS KeyPackages, which are NOT planned to ever be logged in a key transparency system. The KeyPackages will be signed by the keypair whose public component is stored, however.
That seems… strange? Not sure why that approach was chosen.
I’ve written tons about why this approach was taken, but it might be inaccessible to someone with limited knowledge of modern cryptography protocol design. (Authenticated encryption, forward secrecy, context commitment, etc.)
This was my earliest blog post on the topic, if you want a place to start.
I’d describe myself as a relatively knowledgeable layman. Essentially I know enough to use it effectively in a sysadmin/dbadmin capacity, but not got a good grasp of the underlying math.
This was my earliest blog post on the topic, if you want a place to start.
The biggest unsolved problem in public key cryptography is knowing that a public key belongs to a particular individual. Making sure an attacker hasn’t swapped out keys or is impersonating you is a problem.with a non trivial solution
The user would be unable to use E2EE as soon as the key is swapped, so the only real issue here is impersonation.
If an admin mitms all the messages then they can re-encrypt using the users original/real public key, leaving the user unaware that they have been hacked and able to use encryption as normal, or am I missing something?
That would rely on the contact of that user using the admin’s public key. In most systems I’ve seen that’d result in a big flashing warning that the user’s key has been changed. So, dangerous for people contacting you for the first time, much more obvious if the 2 users have been talking before that point.
Other people have raised the much more interesting and potentially dangerous point that it’s very difficult in this context to make sure that a particular public key corresponds with a particular user. I’m way more used to sysadmin style issues where you have a small number of known keypairs, while in this context it’s a large number of mostly unknown keypairs, so you need some way of confirming that. I’m starting to understand why this is a much thornier issue than it appears on the surface.
As long as the admin doesn’t possess the private key, that solution still prevents the latter issue. If the admin swaps out your public key for one they control, they could technically impersonate you and read messages after the swap, but not read any messages from before. The user would be unable to use E2EE as soon as the key is swapped, so the only real issue here is impersonation.
An admin could theoretically take over a user’s account today, so there’s not really a new vulnerability here. And with E2EE, there’d be a big clue about something funky happening with the public key changing.
EDIT: Oh.
That seems… strange? Not sure why that approach was chosen.
How much do you know about cryptography?
I’ve written tons about why this approach was taken, but it might be inaccessible to someone with limited knowledge of modern cryptography protocol design. (Authenticated encryption, forward secrecy, context commitment, etc.)
This was my earliest blog post on the topic, if you want a place to start.
I’d describe myself as a relatively knowledgeable layman. Essentially I know enough to use it effectively in a sysadmin/dbadmin capacity, but not got a good grasp of the underlying math.
Thank you, I’ll take you up on that.
The biggest unsolved problem in public key cryptography is knowing that a public key belongs to a particular individual. Making sure an attacker hasn’t swapped out keys or is impersonating you is a problem.with a non trivial solution
If an admin mitms all the messages then they can re-encrypt using the users original/real public key, leaving the user unaware that they have been hacked and able to use encryption as normal, or am I missing something?
That would rely on the contact of that user using the admin’s public key. In most systems I’ve seen that’d result in a big flashing warning that the user’s key has been changed. So, dangerous for people contacting you for the first time, much more obvious if the 2 users have been talking before that point.
Other people have raised the much more interesting and potentially dangerous point that it’s very difficult in this context to make sure that a particular public key corresponds with a particular user. I’m way more used to sysadmin style issues where you have a small number of known keypairs, while in this context it’s a large number of mostly unknown keypairs, so you need some way of confirming that. I’m starting to understand why this is a much thornier issue than it appears on the surface.