OK, I see a "Threat Model" section is added. I'd encourage the author to read about how to create a good formal threat model, like https://docs.microsoft.com/e

OK, I see a "Threat Model" section is added. I'd encourage the author to read about how to create a good formal threat model, like https://docs.microsoft.com/en-us/learn/modules/tm-introduction-to-threat-modeling/ https://docs.microsoft.com/en-us/learn/modules/tm-introducti.... That said, to pick this apart a bit: > Also consider the threat in case a Messenger is compelled by the its local government to leak keys on the client (say through an app update) or server by warrant, or there is a rogue employee at Messenger company who compromises. Of course an e2ee messenger like Signal cannot leak keys via server compromise. > Often a high security environment will compile its own version of Signal's open source client, however it will be days or weeks old and have published vulnerabilities. [citation needed] > Horcruxes would allow the high security user to send 1 horcrux on the custom compiled Signal version, and another horcrux on the public app store version (in addition to others), thus increasing the cost significantly of hacking all horcruxes. What are those vulnerabilities? If they're RCEs or similar, I fail to see how this helps. If they're vulnerabilities in the Signal protocol--well, as I said, [citation needed]. > Horcruxes sent on separate devices/OSs/channels increase costs linearly for 0-day vulnerabilities on apps and OS's. No, they decrease costs linearly for 0days. > Specifically, we assume that one nation state, for one messaging channel, a nation-state observer: [snip] > Can compel providers in their nation to serve malicious code to their users So as I noted before, the only threat model for which this system appears to make any sense is one where attackers can serve malicious updates to off-the-shelf messaging systems. I'm going to talk about that threat model alone. (If there are others, I'm happy to discuss them!) While this is a serious concern (and is the reason that code signing, binary transparency, and similar exist--likely far more practical solutions to this problem), fundamentally this scheme merely begs the question: if I can't trust code that has access to the message plaintext, how am I going to implement this system? (Certainly the thing that does the XOR and splitting and QR code whatnot may be simpler code than a full-featured e2ee messaging app, so maybe easier to audit. But pen and paper is even easier to audit!) It sounds like at heart what we need is pen-and-paper cryptography where we then share the OTP over one channel and the ciphertext over another. And that is a reasonable approach if you truly cannot trust your computing stack. (Of course, if you're going to go that far, you might as well just meet face-to-face and exchange a large one-time pad. Then you wouldn't need to muck about with multiple "horcruxes" anyway!)