5 ms·

OTP is sent over one of the two channels (or m of n). The lint is that the pad has effectively the same security as the message itself. In terms of explaining,

by md_ 6y ago

OTP is sent over one of the two channels (or m of n). The lint is that the pad has effectively the same security as the message itself. In terms of explaining, try to describe specific threats (including what the attacker can and cannot do, ideally with a real-world example). E.g. can your attacker: * Observe ciphertext? Do they have global network MTIM? (Passive or active?) * Break e2ee? For example, do they have the ability to derive messages from merely passively observing ciphertext? * Compel service providers to share any data the provider has? * Compel providers to serve malicious code to their users? Etc. This proposal is missing any formal threat model, so it’s hard to evaluate what it’s intended to do. I cannot immediately come up with a threat model where this makes sense, unfortunately.

ljlolel 6y ago
>OTP is sent over one of the two channels (or m of n). The lint is that the pad has effectively the same security as the message itself. Yes! Exactly, that's the brilliant part of this. There is symmetric trust (distrust really) of every channel. We equally distrust all channels a bit, and expect them to be exploitable by different non-overlapping parties (see Venn diagram). In old times you couldn't do this since there weren't so many ways to communicate, and they were all insecure except one very very expensive one. Nowadays, there are multiple channels people use which are all mostly secure using modern crypto, except for some very specific vulnerabilities and state-sponsored attacks, but usually only from 1 or otherwise very expensive per attack. That's the innovation that Horcruxes exploits! Do you see? There is a section on Threat Model, also if you just think about it you can imagine the threat models yourself, looking at what it does and the use cases. I've added those explicitly into that section.
- maqp 6y ago
  "We equally distrust all channels a bit" The problem is you're proposing a scheme that's completely insecure if all channels are being watched by the same entity. The fact you're not employing public key encryption to mitigate this issue is really weird. "expect them to be exploitable by different non-overlapping parties (see Venn diagram)." Don't. NSA knew about the Sony hacks because they had hacked the systems of North Korea's cyber army. There's no telling if they're inside e.g. WeChat's servers. Cryptographic security is on so different level it's hard to emphasize it. Perhaps a comparison to computational effort would suffice: Let's say a zero-day exploit to compromise one server costs 1,000,000 USD. Let's say brute forcing an 80-bit key also costs 1,000,000 USD. Let's say you're using two servers to deliver the alone unbreakable horcrux halves. It's costing exactly 2,000,000 USD to recover the message This is the equivalent to brute forcing an 81-bit key. My point is, it's much cheaper to break the channels than it is to break the encryption keys that start from around 128 bits and go up to 256 bits. "In old times you couldn't do this since there weren't so many ways to communicate, and they were all insecure except one very very expensive one." In the old times there was no encryption whatsoever in Yahoo Messenger, MSN messenger etc. In the old times there was no E2EE so you only had to hack the servers to get access to massive amounts of user data (this still holds true for some shit services, e.g. Telegram). "--except for some very specific vulnerabilities and state-sponsored attacks" State sponsored attacks are about hacking endpoints, like Besos' WhatsApp. And Horcrux doesn't solve this in any way. Even if your magic wand is an airgapped device. See https://ieeexplore.ieee.org/document/7122176 https://ieeexplore.ieee.org/document/7122176 and https://www.computer.org/csdl/magazine/co/2015/07/mco2015070059/13rRUNvgyZk https://www.computer.org/csdl/magazine/co/2015/07/mco2015070...
md_ 6y ago
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!)
- 6y ago

by md_ 6y ago

ljlolel 6y ago

>OTP is sent over one of the two channels (or m of n). The lint is that the pad has effectively the same security as the message itself. Yes! Exactly, that's the brilliant part of this. There is symmetric trust (distrust really) of every channel. We equally distrust all channels a bit, and expect them to be exploitable by different non-overlapping parties (see Venn diagram). In old times you couldn't do this since there weren't so many ways to communicate, and they were all insecure except one very very expensive one. Nowadays, there are multiple channels people use which are all mostly secure using modern crypto, except for some very specific vulnerabilities and state-sponsored attacks, but usually only from 1 or otherwise very expensive per attack. That's the innovation that Horcruxes exploits! Do you see? There is a section on Threat Model, also if you just think about it you can imagine the threat models yourself, looking at what it does and the use cases. I've added those explicitly into that section.

maqp 6y ago
"We equally distrust all channels a bit" The problem is you're proposing a scheme that's completely insecure if all channels are being watched by the same entity. The fact you're not employing public key encryption to mitigate this issue is really weird. "expect them to be exploitable by different non-overlapping parties (see Venn diagram)." Don't. NSA knew about the Sony hacks because they had hacked the systems of North Korea's cyber army. There's no telling if they're inside e.g. WeChat's servers. Cryptographic security is on so different level it's hard to emphasize it. Perhaps a comparison to computational effort would suffice: Let's say a zero-day exploit to compromise one server costs 1,000,000 USD. Let's say brute forcing an 80-bit key also costs 1,000,000 USD. Let's say you're using two servers to deliver the alone unbreakable horcrux halves. It's costing exactly 2,000,000 USD to recover the message This is the equivalent to brute forcing an 81-bit key. My point is, it's much cheaper to break the channels than it is to break the encryption keys that start from around 128 bits and go up to 256 bits. "In old times you couldn't do this since there weren't so many ways to communicate, and they were all insecure except one very very expensive one." In the old times there was no encryption whatsoever in Yahoo Messenger, MSN messenger etc. In the old times there was no E2EE so you only had to hack the servers to get access to massive amounts of user data (this still holds true for some shit services, e.g. Telegram). "--except for some very specific vulnerabilities and state-sponsored attacks" State sponsored attacks are about hacking endpoints, like Besos' WhatsApp. And Horcrux doesn't solve this in any way. Even if your magic wand is an airgapped device. See https://ieeexplore.ieee.org/document/7122176 https://ieeexplore.ieee.org/document/7122176 and https://www.computer.org/csdl/magazine/co/2015/07/mco2015070059/13rRUNvgyZk https://www.computer.org/csdl/magazine/co/2015/07/mco2015070...

md_ 6y ago

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!)

6y ago