4 ms·

If I intercepted the message... I would try to change the location in the key to use. Especially to one that had already been used. I would try to replace th

If I intercepted the message... I would try to change the location in the key to use. Especially to one that had already been used. I would try to replace the message, salt, and hash entirely. I would try to fiddle bits. I would compile all of the messages, looking for when the pad had been re-used. I would try to decipher messages, I would try to corrupt messages, I would try to inject my own messages, I would try to use a denial-of-service to prevent you from communicating at all, I would try to force you to consume your entire key to transmit your first message. I would re-transmit old messages, and see how you behaved. I would send cleartext messages telling you that the sender had been abducted, and that you couldn't trust any further messages, sending it as a "trusted associate," or sister, or parent. I would try to gain physical access to the hard drive, and copy it. Having gained access, I could inject all of my own messages, and deny you the ability to communicate at all. I really, honestly, don't think that my proposed system is any more or less secure than any communication system that would rely upon quantum entanglement to deliver a supposedly secure keystream to both ends. But it would cost many orders of magnitude less.

tptacek 15y ago
I wouldn't use QC. I'd use conventional encryption. Think about what happens given any known plaintext. Think about the difference between a MAC and a simple encrypted hash. I'm not giving you random political scenarios or whatnot; I'm looking at this like a simple engineering problem; the benchmark is TLS, not "some theoretical thing that the NSA can't break" or whatever. I shouldn't have made fun of you to begin with (making fun of people who suggest one time pads is a time-honored sci.crypt tradition that doesn't need propagating). So bear with me. I'm just trying to show you how irritating it is to get a simple encrypted transport right.
- VikingCoder 15y ago
  If you know any plaintext, then you know the OTP that corresponds to that one section of the key, and you know the salt that was used for that one hash. Since I will never use, or accept, that portion of the OTP again, this doesn't gain you the ability to decypher a message, or fake a message without detection. If you both know the plain text, and you have prevented transmission of my original message, then you have that many bytes of OTP that you could use to send that many bytes of faked messages. If there is another cryptography system you would like to use to encrypt the plaintext, before sending it through my proposed system, then knowing just the plaintext would not help you. Making fun of people who THINK they're using OTP is the time-honored tradition. I'm proposing to ACTUALLY use OTP. I acknowledge that someone who intercepts all of our messages can prohibit us from communicating. But they can't fake messages. I acknowledge that if someone steals our key, we are compromised - but that is true of any system. I acknowledge that transport is hard. You do not accept QC. Okay, I'm not going to win you over. If you accept QC, then I offer up that physical transport of a OTP is just as secure, and orders of magnitude cheaper. Whatever MAC / transport systems have been used for QC, can be used by my proposed system. I am no better, or worse, than they are.
  - tptacek 15y ago
    No, using an OTP isn't actually better. The problems I'm talking about don't depend on keystream reuse; they depend on the fact that you don't have "keys", you have a single keystream. A real, sound cryptosystem would use keys in at least two places in the protocol (once to provide confidentiality for the message, and once to provide integrity).
    - VikingCoder 15y ago
      I use the OTP to encrypt the message. I use the OTP as salt for a hash to verify. Confidentiality, and integrity.
      - tptacek 15y ago
        Or it would be if "simply concatenating a keystream with a secure hash function" created a secure MAC, which it doesn't. You see what I mean about "yes-but"-ing ones way into treacherous confidence. Believe me when I say that a lot of systems have been deployed using this same design process, and all of them failed --- it is hard to name a well-designed cryptosystem that didn't succumb to spectacular failures. And, on another tangent, you can see how your design now begs a pretty big question: between AES and SHA-256, virtually everyone would agree that SHA-256 is the less sound primitive (they're both "sound", but SHA-2 will fall before AES, which is why we're busily selecting SHA-3 right now). Concern about AES drives you to contemplate OTPs, but forces you to rely on something like SHA-2. An AES design could use AES both for confidentiality and integrity. Either way, you're not getting "perfect" security; you have all the downsides of OTPs and none of the upside. OTP's are kind of silly.
        VikingCoder 15y ago
        Thank you for all of your responses. Unfortunately, all you've done is tell me "it won't work." When you attempt to inform me why it won't work, your answers boil down to "because." Why doesn't concatenating "MESSAGE XOR OTP" with "HASH(OTP-SALT, MESSAGE)" both a) provide confidentiality for the message, and B) provide integrity? It certainly provides confidentially for the message. Without knowing the OTP I use, you will not decipher the message. And by using another portion of the OTP as a unique, one-time salt for a hashing function (I don't care which hashing function), I am preventing a man in the middle from twiddling bits undetected. If you want to tell me that I'm wrong - that's great. If you want to explain why I'm wrong, that would actually be useful. ...and Quantum Cryptography boils down to being a fancy way to generate a OTP. Your argument then becomes, "All of the researchers working on Quantum Cryptography are idiots, and they should know better." Extraordinary claims require extraordinary proof. If your claim is that they can't build a physically secure system, because you can't trust a quantum-entagled particle pair to really arrive at both ends uncorrupted, that's one thing. No, your claim is that the underlying math behind OTP is inherently flawed. Message XOR OTP is not secure, even if the man in the middle does not know the OTP. From the definition on Wikipedia, "A MAC algorithm, sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content." The secret key is a sequence of bytes from my OTP. They have never been used before, and they will never be used again. "While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To be considered secure, a MAC function must resist existential forgery under chosen-plaintext attacks. This means that even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the attacker's choosing, the attacker cannot guess the MAC for other messages without performing infeasible amounts of computation." They cannot guess the MAC for other messages, because they cannot guess the key for other messages, because they do not know the OTP for other messages, because I will never reuse any of my OTP, thus making it a ONE Time Pad. "MACs differ from digital signatures as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with symmetric encryption." No problem. That's what my system does. I tell you what portion of the OTP to use, and you use it. If it's ever been used before, you know the communication channel has been compromised. http://upload.wikimedia.org/wikipedia/commons/0/08/MAC.svg http://upload.wikimedia.org/wikipedia/commons/0/08/MAC.svg The Key (K) is determined by the position in the OTP, specified by the message header.

tptacek 15y ago

I wouldn't use QC. I'd use conventional encryption. Think about what happens given any known plaintext. Think about the difference between a MAC and a simple encrypted hash. I'm not giving you random political scenarios or whatnot; I'm looking at this like a simple engineering problem; the benchmark is TLS, not "some theoretical thing that the NSA can't break" or whatever. I shouldn't have made fun of you to begin with (making fun of people who suggest one time pads is a time-honored sci.crypt tradition that doesn't need propagating). So bear with me. I'm just trying to show you how irritating it is to get a simple encrypted transport right.

VikingCoder 15y ago
If you know any plaintext, then you know the OTP that corresponds to that one section of the key, and you know the salt that was used for that one hash. Since I will never use, or accept, that portion of the OTP again, this doesn't gain you the ability to decypher a message, or fake a message without detection. If you both know the plain text, and you have prevented transmission of my original message, then you have that many bytes of OTP that you could use to send that many bytes of faked messages. If there is another cryptography system you would like to use to encrypt the plaintext, before sending it through my proposed system, then knowing just the plaintext would not help you. Making fun of people who THINK they're using OTP is the time-honored tradition. I'm proposing to ACTUALLY use OTP. I acknowledge that someone who intercepts all of our messages can prohibit us from communicating. But they can't fake messages. I acknowledge that if someone steals our key, we are compromised - but that is true of any system. I acknowledge that transport is hard. You do not accept QC. Okay, I'm not going to win you over. If you accept QC, then I offer up that physical transport of a OTP is just as secure, and orders of magnitude cheaper. Whatever MAC / transport systems have been used for QC, can be used by my proposed system. I am no better, or worse, than they are.
- tptacek 15y ago
  No, using an OTP isn't actually better. The problems I'm talking about don't depend on keystream reuse; they depend on the fact that you don't have "keys", you have a single keystream. A real, sound cryptosystem would use keys in at least two places in the protocol (once to provide confidentiality for the message, and once to provide integrity).
  - VikingCoder 15y ago
    I use the OTP to encrypt the message. I use the OTP as salt for a hash to verify. Confidentiality, and integrity.
    - tptacek 15y ago
      Or it would be if "simply concatenating a keystream with a secure hash function" created a secure MAC, which it doesn't. You see what I mean about "yes-but"-ing ones way into treacherous confidence. Believe me when I say that a lot of systems have been deployed using this same design process, and all of them failed --- it is hard to name a well-designed cryptosystem that didn't succumb to spectacular failures. And, on another tangent, you can see how your design now begs a pretty big question: between AES and SHA-256, virtually everyone would agree that SHA-256 is the less sound primitive (they're both "sound", but SHA-2 will fall before AES, which is why we're busily selecting SHA-3 right now). Concern about AES drives you to contemplate OTPs, but forces you to rely on something like SHA-2. An AES design could use AES both for confidentiality and integrity. Either way, you're not getting "perfect" security; you have all the downsides of OTPs and none of the upside. OTP's are kind of silly.
      - VikingCoder 15y ago
        Thank you for all of your responses. Unfortunately, all you've done is tell me "it won't work." When you attempt to inform me why it won't work, your answers boil down to "because." Why doesn't concatenating "MESSAGE XOR OTP" with "HASH(OTP-SALT, MESSAGE)" both a) provide confidentiality for the message, and B) provide integrity? It certainly provides confidentially for the message. Without knowing the OTP I use, you will not decipher the message. And by using another portion of the OTP as a unique, one-time salt for a hashing function (I don't care which hashing function), I am preventing a man in the middle from twiddling bits undetected. If you want to tell me that I'm wrong - that's great. If you want to explain why I'm wrong, that would actually be useful. ...and Quantum Cryptography boils down to being a fancy way to generate a OTP. Your argument then becomes, "All of the researchers working on Quantum Cryptography are idiots, and they should know better." Extraordinary claims require extraordinary proof. If your claim is that they can't build a physically secure system, because you can't trust a quantum-entagled particle pair to really arrive at both ends uncorrupted, that's one thing. No, your claim is that the underlying math behind OTP is inherently flawed. Message XOR OTP is not secure, even if the man in the middle does not know the OTP. From the definition on Wikipedia, "A MAC algorithm, sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content." The secret key is a sequence of bytes from my OTP. They have never been used before, and they will never be used again. "While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To be considered secure, a MAC function must resist existential forgery under chosen-plaintext attacks. This means that even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the attacker's choosing, the attacker cannot guess the MAC for other messages without performing infeasible amounts of computation." They cannot guess the MAC for other messages, because they cannot guess the key for other messages, because they do not know the OTP for other messages, because I will never reuse any of my OTP, thus making it a ONE Time Pad. "MACs differ from digital signatures as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with symmetric encryption." No problem. That's what my system does. I tell you what portion of the OTP to use, and you use it. If it's ever been used before, you know the communication channel has been compromised. http://upload.wikimedia.org/wikipedia/commons/0/08/MAC.svg http://upload.wikimedia.org/wikipedia/commons/0/08/MAC.svg The Key (K) is determined by the position in the OTP, specified by the message header.