The implementation seems to be libsodium sealed boxes, with the key material sequestered using the juicebox.xyz protocol. In itself this seems broadly fine, wit

The implementation seems to be libsodium sealed boxes, with the key material sequestered using the juicebox.xyz protocol. In itself this seems broadly fine, with the significant proviso as mentioned in https://help.x.com/en/using-x/encrypted-direct-messages https://help.x.com/en/using-x/encrypted-direct-messages that identity is not verified at present, and as a result it's trivially MITMable. But there's something more subtle here. Juicebox means that your key material is remotely stored in encrypted form. In an ideal setup, it's split between multiple different realms operated by different people, and the key material is stored in HSMs. There's a complicated dance where you prove knowledge of the PIN without actually revealing the PIN, and then the remote realms hand over the key material and you reassemble it into your key by decrypting it with a key also derived from your PIN. If Twitter is running their own Juicebox realms then you're having to trust them. Even if the realms are implemented as HSMs, they're in a position to see the encrypted key material as it exits the HSM. And if they're not in HSMs, then the encrypted key material is just sitting there where they can see it. This doesn't intrinsically give them the key, since it still needs the PIN to decrypt it - but the key derivation function from the PIN is just 32 rounds of argon2id with 16MB of memory use, and given the PIN is limited to 4 digits, that's going to take about a second of GPU aided brute forcing to drop out the actual key. As noted in the help doc, this isn't forward secure, so the moment they have the key they can decrypt everything. This is so far from being a meaningful e2ee platform it's ridiculous.