Linux server admin, MySQL/TSQL database admin, Python programmer, Linux gaming enthusiast and a forever GM.

  • 0 posts
  • 2 comments
Joined 3 years ago
Cake day: June 8th, 2023
  • 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.