4 ms·

There is some magical thinking in this proposal as relates to key creation and transmission — I do not think it’s as easy as the author proposes to get enough e

There is some magical thinking in this proposal as relates to key creation and transmission — I do not think it’s as easy as the author proposes to get enough entropy for a one-time pad from QR codes, for instance. A giant QR code gives only 406 bytes, and the ones phones trade are usually smaller. Also, it is easy to scan a QR code automatically by its nature. That said, I reinterpret this idea slightly and think it’s brilliant — to Shamir split a message between different channels is a really good idea. To split them in such a way that different nation-state actors will each encounter significant expense is pretty brilliant. Ultimately, (and I think this is acknowledged), for this to be usable you’re going to need a device that you don’t think is compromised to read and send; In the crypto world, the canonical device would be a formatted flashed older phone that you never turn on data for; it would then use the camera to scan and incorporate the QR codes sent through each channel and recombine them. If that’s the best usability Horcruxes provide, they are going to be used only for ultra-high-value short communication — private keys, passwords, GPS locations of very high value. TL;DR The proposal provides some improved messaging security but at high usability cost. I think it’s probably better than not using it if you use it as an app on your “main” phone, but it doesn’t give full benefits in that mode.

ljlolel 6y ago
Thanks for saying it's brilliant :) Yes, entropy and true randomness will be an issue. I can imagine manufacturing a Magic Wand (all in the US) which would be a custom piece of HW with an entropy chip (maybe using cosmic rays?) Yes you're right and I mention that in the Usability section.
- maqp 6y ago
  How are you ensuring a US-manufactured HWRNG produces random numbers -- i.e. how are you ensuring the NSA doesn't put HW implants to your devices as they're being delivered to your customers? https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
  - ljlolel 6y ago
    oh man, that's rough. Would need to get a US-made HWRNG, and a China HWRNG, and hope at least one isn't compromised??? How would you recommend we get random numbers?
    - maqp 6y ago
      The most practical is to drop the information theoretical promises and use e.g. Linux kernel's GETRANDOM syscall. Or you can outsource the HWRNG building for users who can create it from COTS parts, e.g. http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/ has diagrams for the circuit.
maqp 6y ago
"To split them in such a way that different nation-state actors will each encounter significant expense is pretty brilliant." That's where the concerns start. There's no data about which services are compromised by which entities, no effective threat model, no dissection about the expected capabilities of the attackers. No recommendations for through where to pass the shares. It's not at all clear why'd they recommend WeChat that's not E2EE at all. It's also expanding the TCB by encouraging installation of insecure apps (like WeChat). It's also relying on the assumption it's always the case at least one channel isn't compromised, which is really weird, it would be much better to do airgap-to-airgap public key encryption instead, at least on the inside. That way the networked endpoint(s) receiving the shares is not the weak point of the system. Finally, as was mentioned, the app will leak metadata about the communication to every service used to deliver the shares. "In the crypto world, the canonical device would be a formatted flashed older phone that you never turn on data for" Well that assumes the Baseband processor does not talk to cell towers. Airgapping a mobile device isn't very easy so a cheap netbook might do better. Or, a more modern phone like Librem with mechanical kill switches for cell/wifi would be much better. The problem is also, is the QR-code safe, what if you unknowingly scan an exploit that then exfiltrates data off the airgapped device inside the next QR-code containing a share. It's a nice thought experiment but there's simply not enough benefits to beat the problems, and at most I can see this increase the attacker's cost slightly, instead of automated remote exploitation of single device, they now need to exploit a few devices receiving shares over (possibly E2EE) apps.

ljlolel 6y ago

Thanks for saying it's brilliant :) Yes, entropy and true randomness will be an issue. I can imagine manufacturing a Magic Wand (all in the US) which would be a custom piece of HW with an entropy chip (maybe using cosmic rays?) Yes you're right and I mention that in the Usability section.

maqp 6y ago
How are you ensuring a US-manufactured HWRNG produces random numbers -- i.e. how are you ensuring the NSA doesn't put HW implants to your devices as they're being delivered to your customers? https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
- ljlolel 6y ago
  oh man, that's rough. Would need to get a US-made HWRNG, and a China HWRNG, and hope at least one isn't compromised??? How would you recommend we get random numbers?
  - maqp 6y ago
    The most practical is to drop the information theoretical promises and use e.g. Linux kernel's GETRANDOM syscall. Or you can outsource the HWRNG building for users who can create it from COTS parts, e.g. http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/ has diagrams for the circuit.

maqp 6y ago

"To split them in such a way that different nation-state actors will each encounter significant expense is pretty brilliant." That's where the concerns start. There's no data about which services are compromised by which entities, no effective threat model, no dissection about the expected capabilities of the attackers. No recommendations for through where to pass the shares. It's not at all clear why'd they recommend WeChat that's not E2EE at all. It's also expanding the TCB by encouraging installation of insecure apps (like WeChat). It's also relying on the assumption it's always the case at least one channel isn't compromised, which is really weird, it would be much better to do airgap-to-airgap public key encryption instead, at least on the inside. That way the networked endpoint(s) receiving the shares is not the weak point of the system. Finally, as was mentioned, the app will leak metadata about the communication to every service used to deliver the shares. "In the crypto world, the canonical device would be a formatted flashed older phone that you never turn on data for" Well that assumes the Baseband processor does not talk to cell towers. Airgapping a mobile device isn't very easy so a cheap netbook might do better. Or, a more modern phone like Librem with mechanical kill switches for cell/wifi would be much better. The problem is also, is the QR-code safe, what if you unknowingly scan an exploit that then exfiltrates data off the airgapped device inside the next QR-code containing a share. It's a nice thought experiment but there's simply not enough benefits to beat the problems, and at most I can see this increase the attacker's cost slightly, instead of automated remote exploitation of single device, they now need to exploit a few devices receiving shares over (possibly E2EE) apps.