2 ms·

1) True. Buy a few of them, and XOR them all together. 2) I can always have a Message Digest of my message included. 3) If the Message Digest doesn't match,

1) True. Buy a few of them, and XOR them all together. 2) I can always have a Message Digest of my message included. 3) If the Message Digest doesn't match, the message will not be accepted as valid. The receiver will not be out of sync.

tptacek 15y ago
An encrypted SHA1 hash isn't a MAC. The protocol you outlined would be trivially breakable. You seem pretty smart; give it a few minutes thought and see if you can grok why.
- VikingCoder 15y ago
  If it's trivially breakable, it should be trivial for you to explain how. Magic token, protocol identifier Location in key to use Length of message + salt MESSAGE - XORed against OTP Some salt is taken from the next bit of OTP. Hash of plaintext message If any of that portion of the OTP has been previously used, the message is invalid. If the hash doesn't match, the message is invalid. Under no circumstances is a new message valid if it uses a portion of the OTP that has been used before. I can't guarantee a message will arrive. I believe I am correct in thinking that all messages that arrive and pass these tests, have not been tampered with. If the keys are physically secure, the message is secure.
  - tptacek 15y ago
    If you found this protocol being used in an application you were testing, how would you go about tinkering with it to find attacks? I'm serious, not messing with you. What would be some things you would try to do to get the protocol to misbehave?
    - VikingCoder 15y ago
      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).

tptacek 15y ago

An encrypted SHA1 hash isn't a MAC. The protocol you outlined would be trivially breakable. You seem pretty smart; give it a few minutes thought and see if you can grok why.

VikingCoder 15y ago
If it's trivially breakable, it should be trivial for you to explain how. Magic token, protocol identifier Location in key to use Length of message + salt MESSAGE - XORed against OTP Some salt is taken from the next bit of OTP. Hash of plaintext message If any of that portion of the OTP has been previously used, the message is invalid. If the hash doesn't match, the message is invalid. Under no circumstances is a new message valid if it uses a portion of the OTP that has been used before. I can't guarantee a message will arrive. I believe I am correct in thinking that all messages that arrive and pass these tests, have not been tampered with. If the keys are physically secure, the message is secure.
- tptacek 15y ago
  If you found this protocol being used in an application you were testing, how would you go about tinkering with it to find attacks? I'm serious, not messing with you. What would be some things you would try to do to get the protocol to misbehave?
  - VikingCoder 15y ago
    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).