31–40 of 47 posts
Earlier quoted context omitted.
For one, you don't have a MAC. This means an attacker can flip arbitrary bits in your message. There's a huge difference between crypto primitives and a crypto system. (It seems like it should be possible to devise a non-algorithmic MAC using a second pad. But now we're back in theory-land.)
(It might be possible to devise a non-algorithmic MAC using a second pad, hmm.) AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
Earlier quoted context omitted.
I'm not proposing that you buy my system - I'm asking what's wrong with my design for the core mechanic. And you've genuinely offered no substantive critiques. Sounds like the core mechanic is gold, then. If there's nothing wrong with the core mechanic, I should be able to buy a commercial system built on it, and know that it has all of the inherent strengths and weaknesses of my core mechanic. And possibly more weak…
Thank you. It's people like you who are steadily paying for my kids' college education. :) I don't blame you for being frustrated with my responses, but it's my experience that detailed critiques of random crypto schemes on message boards are counterproductive; the designer just "yes, but"'s the critique until all the low-hanging fruit is picked (each of which was a devastating flaw in their original scheme), and the…
I'm proposing a hard drive and a plane ticket.
Your critique is based upon ego alone.
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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.
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…
I'm serious, not messing with you. What would be some things you would try to do to get the protocol to misbehave?
If I'm understanding this correctly, the "serious flaw" recently uncovered is that if the manufacturer of the crypto devices is malicious, the crypto devices can be made to be insecure. Despite the fact that this same "serious flaw" exists with classical cryptography devices, only worse (since the quantum attack doesn't reveal plaintext A until B is sent). (Disclosure: haven't bothered to read the arXicle.)
Quantum key distribution (QKD) promises security based on the laws of quantum physics, and not on computational assumptions. However, in practice, QKD experiments have been attacked through side channels. One possible side channel comes from a malicious manufacturer. Side-channel attacks also affect classical cryptography, of course, but might be more important for QKD because:
1. Quantum devices are harder to build and test, and less understood, than classical devices, so side-channel attacks might be easier, at least for now.
2. The goal of QKD has always been to reach higher security than is possible classically.
"Device-independent" (DI) QKD solves this problem. DIQKD allows for extracting a secure key even if the crypto devices are manufactured by your enemy. This should be hard to believe; it is completely impossible classically. It is very cool that it is (probably) possible quantumly.
I say "probably" because full DIQKD security proofs do not yet exist; giving a full proof is a major open problem in the field. From the perspective of people in the field, the next step in the DIQKD roadmap would be to deploy a DIQKD experiment. Although standard QKD schemes are even commercially available these days, deploying a DIQKD scheme is another major open problem because the schemes proposed currently are far too inefficient to be practical and require noise rates below current photon detector technology.
The new paper says that we should reconsider this roadmap. Even if we are able to give a DIQKD security proof, there is still a problem, because when you reuse untrusted devices they can leak previously generated keys. I don't have a lot of time to explain this and don't know that it is an especially novel observation. It can probably be worked around with more sophisticated key-generation methods. But that's essentially the current status.
Earlier quoted context omitted.
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…
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?
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.
Earlier quoted context omitted.
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?
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 t…
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.
Earlier quoted context omitted.
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 t…
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 wi…
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.
Earlier quoted context omitted.
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 wi…
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…
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).