Why are X's 'encrypted DMs' and 'XChat' not so good?

X (formerly Twitter) has an encrypted DM feature, and is expected to add a new enhanced DM feature called XChat. Elon Musk has been criticized for claiming that XChat has 'Bitcoin-style encryption,' but developer Matthew Garrett has pointed out that X's encryption is not very good in the first place.
mjg59 | Twitter's new encrypted DMs aren't better than the old ones
mjg59 | How Twitter could (somewhat) fix their encrypted DMs
https://mjg59.dreamwidth.org/71933.html
In May 2023, when X was still called Twitter, it introduced the “encrypted DM” feature.
Twitter launches 'encrypted direct mail' service, Elon Musk says 'you can't access it even if you're held up at gunpoint' - GIGAZINE

Messages sent and received using the encrypted DM feature were basically only accessible to the parties involved, and Twitter was not able to access the contents. However, Linux developer Matthew Garrett described the encrypted DM feature as 'technically end-to-end encryption, but it's something that Twitter could relatively easily inject a new encryption key and get everyone's messages,' calling it 'the worst end-to-end encryption.'
About two years later, it was announced that XChat, an enhanced DM feature, would be added to X. However, Elon Musk's claim that XChat has 'implemented Bitcoin-style encryption,' was criticized by core developers, who said, 'Bitcoin doesn't use encryption in the first place.'

According to Garrett, the previous implementation of encrypted DMs involved clients generating key pairs and pushing the public key to Twitter, with each client on each device and browser having its own private key, and messages were encrypted to all public keys associated with the account. This meant that new devices could not decrypt old messages, and there were issues with the maximum number of devices and scaling.
XChat uses the Juicebox protocol to store private keys, which can be retrieved on other devices.
Juicebox | An open-source encryption key recovery protocol

It's not that Company X has the private key, but rather that the encryption key is generated using your PIN, and the stored copy of the private key is encrypted with the encryption key, so that the key cannot be decrypted without knowing the PIN. If you request the key too many times with the wrong PIN, access is locked.
However, this is only possible if the Juicebox backend is trustworthy, Garrett said. If the backend is controlled by someone who cannot be trusted, it is possible to obtain the encrypted private key. In this case, all that is needed to decrypt it is the PIN. X has fixed the PIN to four digits, so the maximum number of attempts is 10,000.
Juicebox defends itself by splitting the key across multiple backends and calling only a portion of each to restore the original. Google and Apple have established procedures to make it difficult to retrieve backed-up keys. In the case of X, it seems that they have three backends and call at least two pieces of data, but all of the backends used are under x.com, so they are considered to be under X's control. In addition, there is no documentation on how to make it difficult to retrieve the key, and Garrett said, 'There is nothing to prove that the backends are trustworthy.'
Garrett concludes, 'Singal doesn't have these drawbacks in the first place, so use Signal.'
Related Posts:
in Web Service, Posted by logc_nt