3 ms·

From the documentation: "Often the 0-days are targeting the most common platforms, so using a lesser used platform increases the attack cost linearly or superl

by maqp 6y ago

From the documentation: "Often the 0-days are targeting the most common platforms, so using a lesser used platform increases the attack cost linearly or superlinearly." There's only so many platforms. The exploit would either be directed against the app itself or the OS or some other popular software package like SSH server running on the endpoint. The threat model of Horcrux doesn't differ from Signal: both are effectively networked TCBs. This will hold unless you explicitly spec it to run on other systems like airgapped, or split TCB configurations. "Horcruxes now open up new possibilities." What the world needs is less vague marketing language, and more concrete examples.

ljlolel 6y ago
What is TCB? > What the world needs is less vague marketing language, and more concrete examples. Please chill out with the attacks, this is an idea I'm not selling anything. There's a multi-page doc describing it in detail, not vague at all. Threat Models enhancement over Signal described in the doc: ## Threat Model One set of threats this protects agains is any for which people would use Signal for: encrypted security. 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. 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. 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.
- maqp 6y ago
  "Please chill out with the attacks" I'm not attacking you, just the concept. The goal is not to hurt you, but to protect others. Please don't take it personally! "What is TCB?" https://en.wikipedia.org/wiki/Trusted_computing_base https://en.wikipedia.org/wiki/Trusted_computing_base "One set of threats this protects agains is any for which people would use Signal for: encrypted security." Well, yes, confidentiality is the desired property of encrypted messengers. "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" I'm not sure what the EARN IT / LAED bill's status is, but for now what holds is US vs Bernstein that established code as speech, and thus protected with 1st amendment, which includes backdoors (effectively compelled speech, also protected under the 1st). Also, Signal has pledged to move abroad if the bills pass. Given that the clients are reproducible and FOSS, I'm going to take any claim that the US government can just force a die-hard cypherpunk like Moxie to add a backdoor and keep that quiet with all his contacts at the ACLU and thee EFF, with a truck-load of salt. "rogue employee at Messenger company who compromises." The git tree is a rather permanent log for who merges a backdoor into the code. Also, there's most likely some form of code review especially wrt security critical code. "Often a high security environment will compile its own version of Signal's open source client" Citation needed. Also, why wouldn't the independently compiled client also update itself automatically via Signal's servers? It's not like the APK version (https://signal.org/android/apk/ https://signal.org/android/apk/) doesn't also update itself. "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" The thing is, Signal can only be compromised by hacking the endpoint, as can Horcrux. If you're relying on the secrecy of the CT delivery mechanisms, you're essentially attempting security through obscurity that only adds log2(n) bits of security where n is the number of possible delivery paths.
  - ljlolel 6y ago
    I think you're still missing many points of this. The idea of trust Signal no matter what is funny though.
    - maqp 6y ago
      There's other stuff protecting you when it comes to Signal: FOSS code, professional audits, reproducible builds etc. If you can't trust networked TCB there's not much you can do anyway. Adding one or more networked TCBs that also need to be compromised isn't going to turn into anything magical. It's about the architecture, and if you need architecture of "no sensitive key/pt material on networked device(s)", you're out of options quite fast. It's either airgaps (shown to be weak as I linked the IEEE etc. articles above), or split TCBs (AFAIK my research on that is the only public work available).

by maqp 6y ago

ljlolel 6y ago

What is TCB? > What the world needs is less vague marketing language, and more concrete examples. Please chill out with the attacks, this is an idea I'm not selling anything. There's a multi-page doc describing it in detail, not vague at all. Threat Models enhancement over Signal described in the doc: ## Threat Model One set of threats this protects agains is any for which people would use Signal for: encrypted security. 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. 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. 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.

maqp 6y ago
"Please chill out with the attacks" I'm not attacking you, just the concept. The goal is not to hurt you, but to protect others. Please don't take it personally! "What is TCB?" https://en.wikipedia.org/wiki/Trusted_computing_base https://en.wikipedia.org/wiki/Trusted_computing_base "One set of threats this protects agains is any for which people would use Signal for: encrypted security." Well, yes, confidentiality is the desired property of encrypted messengers. "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" I'm not sure what the EARN IT / LAED bill's status is, but for now what holds is US vs Bernstein that established code as speech, and thus protected with 1st amendment, which includes backdoors (effectively compelled speech, also protected under the 1st). Also, Signal has pledged to move abroad if the bills pass. Given that the clients are reproducible and FOSS, I'm going to take any claim that the US government can just force a die-hard cypherpunk like Moxie to add a backdoor and keep that quiet with all his contacts at the ACLU and thee EFF, with a truck-load of salt. "rogue employee at Messenger company who compromises." The git tree is a rather permanent log for who merges a backdoor into the code. Also, there's most likely some form of code review especially wrt security critical code. "Often a high security environment will compile its own version of Signal's open source client" Citation needed. Also, why wouldn't the independently compiled client also update itself automatically via Signal's servers? It's not like the APK version (https://signal.org/android/apk/ https://signal.org/android/apk/) doesn't also update itself. "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" The thing is, Signal can only be compromised by hacking the endpoint, as can Horcrux. If you're relying on the secrecy of the CT delivery mechanisms, you're essentially attempting security through obscurity that only adds log2(n) bits of security where n is the number of possible delivery paths.
- ljlolel 6y ago
  I think you're still missing many points of this. The idea of trust Signal no matter what is funny though.
  - maqp 6y ago
    There's other stuff protecting you when it comes to Signal: FOSS code, professional audits, reproducible builds etc. If you can't trust networked TCB there's not much you can do anyway. Adding one or more networked TCBs that also need to be compromised isn't going to turn into anything magical. It's about the architecture, and if you need architecture of "no sensitive key/pt material on networked device(s)", you're out of options quite fast. It's either airgaps (shown to be weak as I linked the IEEE etc. articles above), or split TCBs (AFAIK my research on that is the only public work available).