4 ms·

Hyperbolic claims aside†, I think this is a practical way to dramatically increase the security of OTP key transmission over networked communication. It's not p

Hyperbolic claims aside†, I think this is a practical way to dramatically increase the security of OTP key transmission over networked communication. It's not perfect, but it would make any attacker's job harder, right? E.g. attacker may have no idea where the OTP key is sent, nor on what messaging platform, and would need to crack earlier messages to potentially find out what the communicators were using for all other parts of the horcrux cohort. That's a chicken and egg problem for the attacker. The information on exactly where and what the other horcruxes are could be residing entirely elsewhere in a very encrypted way, or even discussed in person. [†] I'm interested in the hyperbolic claims about OTP in and of itself bringing 'perfect secrecy' via networked communication. Aren't the mechanisms to transmit OTP keys (i.e. the transport mechanisms over the network) prone to weaker security than the OTP mechanism itself? But again, I think that's what this idea helps mitigate.

md_ 6y ago
Right, you're spot on about the OTP. The pad is itself transmitted over the same channel(s) as the message, so there's no value in using an OTP per se. I think the author was just going for a way to split a message in a way that one needs all parts of the split message (or key) to decrypt it. I'm not sure I buy your argument for the value this may provide, though. * The question you pose for an attacker--which platform and which device/identity was used to send a message of interest--already exists, in a more general form, for any attacker. Our threat model presumes the attacker has solved it, or else we wouldn't need e2ee to begin with. * If you're going to discuss something in person, instead of discussing how to use a small number of different channels or identities, just share cryptographic keys! It's my strong sense that the author is mostly ignorant of encryption itself (hence the misuse of OTP) and instead is trying to solve for the problem of lawful intercept (and hence the digression about supply chain security). This is a somewhat reasonable concern, but I don't think the proposal does much to help with it. As I noted above, barring assumptions of extremely pervasive full stack compromise (or full compromise of common cryptographic primitives, an air-gapped dedicated device for encrypting messages with preshared keys provides all the security of this scheme, reduces risk (e.g. of 0days), and is far more usable.
- ljlolel 6y ago
  OTP is not sent over the same channel. Is there some other way I can explain it better, maybe a specific section on a Threat Model (there's a vulnerabilities section to include things not in the threat model).
  - 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
"Hyperbolic claims aside†, I think this is a practical way to dramatically increase the security of OTP key transmission over networked communication." I get you, you're thinking, it's safe as long as one of the channels is not tapped by the same entity. But the problem is this: You're relying on the assumption at least one of the channels is safe. The point of public key cryptography is to protect communication even if none of them are safe. The best the adversary can do in those scenarios is MITM attack, which can be detected over an authenticated channel. "It's not perfect, but it would make any attacker's job harder, right?" It's much easier and cheaper to hack WeChat's non-E2EE messaging app service to steal the OTP keys that decrypt the messages, than it is to break e.g. Curve25519. "That's a chicken and egg problem for the attacker." It's not. All the attacker needs to do is look at the metadata like TCP headers, to see what servers the device talks to. Also note that the author does not propose any remedy to this problem, especially not a single mention of Tor. "The information on exactly where and what the other horcruxes are could be residing entirely elsewhere in a very encrypted way, or even discussed in person." It's a bit much to assume peers are willing to play secret agent, perform periodic rendezvous to exchange OTP material etc. Also, the problem with SSS is, pieces are created on demand, in that sense using multiple OTPs is better. "Aren't the mechanisms to transmit OTP keys -- prone to weaker security than the OTP mechanism itself?" Yes, practically always. The only way to do it more securely is in via sneakernet, in person. This would apply even if you'd do quantum key distribution (e.g. the BB84 requires the Carter-Wegman MAC's key to be pre-shared to authenticate transmission's basis and thus that no OTP interception took place). And that's not something you want to keep doing, thus PSKs are much more usable and thus more secure a choice.

md_ 6y ago

Right, you're spot on about the OTP. The pad is itself transmitted over the same channel(s) as the message, so there's no value in using an OTP per se. I think the author was just going for a way to split a message in a way that one needs all parts of the split message (or key) to decrypt it. I'm not sure I buy your argument for the value this may provide, though. * The question you pose for an attacker--which platform and which device/identity was used to send a message of interest--already exists, in a more general form, for any attacker. Our threat model presumes the attacker has solved it, or else we wouldn't need e2ee to begin with. * If you're going to discuss something in person, instead of discussing how to use a small number of different channels or identities, just share cryptographic keys! It's my strong sense that the author is mostly ignorant of encryption itself (hence the misuse of OTP) and instead is trying to solve for the problem of lawful intercept (and hence the digression about supply chain security). This is a somewhat reasonable concern, but I don't think the proposal does much to help with it. As I noted above, barring assumptions of extremely pervasive full stack compromise (or full compromise of common cryptographic primitives, an air-gapped dedicated device for encrypting messages with preshared keys provides all the security of this scheme, reduces risk (e.g. of 0days), and is far more usable.

ljlolel 6y ago
OTP is not sent over the same channel. Is there some other way I can explain it better, maybe a specific section on a Threat Model (there's a vulnerabilities section to include things not in the threat model).
- 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

"Hyperbolic claims aside†, I think this is a practical way to dramatically increase the security of OTP key transmission over networked communication." I get you, you're thinking, it's safe as long as one of the channels is not tapped by the same entity. But the problem is this: You're relying on the assumption at least one of the channels is safe. The point of public key cryptography is to protect communication even if none of them are safe. The best the adversary can do in those scenarios is MITM attack, which can be detected over an authenticated channel. "It's not perfect, but it would make any attacker's job harder, right?" It's much easier and cheaper to hack WeChat's non-E2EE messaging app service to steal the OTP keys that decrypt the messages, than it is to break e.g. Curve25519. "That's a chicken and egg problem for the attacker." It's not. All the attacker needs to do is look at the metadata like TCP headers, to see what servers the device talks to. Also note that the author does not propose any remedy to this problem, especially not a single mention of Tor. "The information on exactly where and what the other horcruxes are could be residing entirely elsewhere in a very encrypted way, or even discussed in person." It's a bit much to assume peers are willing to play secret agent, perform periodic rendezvous to exchange OTP material etc. Also, the problem with SSS is, pieces are created on demand, in that sense using multiple OTPs is better. "Aren't the mechanisms to transmit OTP keys -- prone to weaker security than the OTP mechanism itself?" Yes, practically always. The only way to do it more securely is in via sneakernet, in person. This would apply even if you'd do quantum key distribution (e.g. the BB84 requires the Carter-Wegman MAC's key to be pre-shared to authenticate transmission's basis and thus that no OTP interception took place). And that's not something you want to keep doing, thus PSKs are much more usable and thus more secure a choice.