3 ms·

A few points: * The 0day argument (that using multiple apps reduces exposure) is a poor one. If we're talking about 0days that allow message decryption from a

by md_ 6y ago

A few points: * The 0day argument (that using multiple apps reduces exposure) is a poor one. If we're talking about 0days that allow message decryption from a MITM, this is true--but if we're talking about RCE with (on mobile OSes) a local sandbox escape (e.g. https://threatpost.com/whatsapp-zero-day-exploited-in-targeted-spyware-attacks/144696/ https://threatpost.com/whatsapp-zero-day-exploited-in-target...), then installing more apps increases the attack surface and thus the risk. * Another argument for multiple services seems to be some implied DOS resistance. But of course exactly the opposite is true: if you split your message and deliver it via multiple channels, any one of those channels can be taken offline and thus thwart message delivery. * The real argument for multiple services seems to be based on an assumed threat model of an attacker who primarily relies on lawful intercept orders, not on technical capabilities (e.g., a warrant, not cryptanalysis). Adding multiple services may do little or nothing for the latter threat, since many messaging services rely on the same underlying protocols (e.g. the Signal Protocol) or the same crypto primitives. This is important for my next point: * If the threat model is about lawful intercepts, and you actually trust modern crypto, this entire scheme makes no sense. Just share a public key for a common, well-vetted algorithm. Encrypting messages using an air-gapped device makes sense. * Further, if we trust crypto, this scheme's sole value is effectively in contact (or public key) discovery: assuming you can't meet face-to-face, the point of this scheme is really to allow multiple services to help you discover a contact's public key (assuming we replace the unnecessary OTP approach with public key exchanges). But many (most?) of these services rely on the telephone system for identity--so there's still a fairly trivial single point of failure, commonly controlled by the government. * To beat a dead horse: if we don't trust modern crypto, it's likely an adversary can access all components of the message+OTP anyway (even without lawful intercept capabilities), so this scheme adds no value. Summary: This proposal would benefit by a more clearly stated threat model. As-is, it's hard to come up with a coherent threat model where this proposal adds value.

mindfulhack 6y ago
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
Avoiding the mobile OS sandbox escape I mentioned in a few places, and you'd use multiple devices and OS's as described.
- deleted 6y ago
  [deleted]
maqp 6y ago
"Another argument for multiple services seems to be some implied DOS resistance. But of course exactly the opposite is true: if you split your message and deliver it via multiple channels, any one of those channels can be taken offline and thus thwart message delivery." Let's remember Shamir's scheme also allows recovery of the message as long as the threshold of minimum amount of shares is exceeded. But otherwise I agree with your thoughtful assessment.

by md_ 6y ago

mindfulhack 6y ago

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

Avoiding the mobile OS sandbox escape I mentioned in a few places, and you'd use multiple devices and OS's as described.

deleted 6y ago
[deleted]

maqp 6y ago

"Another argument for multiple services seems to be some implied DOS resistance. But of course exactly the opposite is true: if you split your message and deliver it via multiple channels, any one of those channels can be taken offline and thus thwart message delivery." Let's remember Shamir's scheme also allows recovery of the message as long as the threshold of minimum amount of shares is exceeded. But otherwise I agree with your thoughtful assessment.