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.)
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).
How would you do this with classical cryptography?
Isn't the point about this particular flaw that it is pretty much undetectable (other than inspecting the hardware itself (which is outside the scope of the article that treats it as a black box)). If the same were to be implemented on classical cryptography it would be comparatively trivial to detect if someone tried to sneak in an old message interleaved with a new message (you know the plaintext + key and thus you know exactly what that will generate).
The compelling argument for quantum cryptography is that it is provably secure (well, that's the theory) and it is quite difficult to prove that the hardware has not been tampered with.
The thing you could do with classical cryptography is to in some way "leak" the key (such as what debian inadvertently did with openssl) but the whole point of quantum cryptography is to have a perfect key distribution to combat any known or unknown attacks.
I read it and you're right. I'm puzzled as to why they would think this 'scuppers' all of quantum cryptography. They also mention imperfect hardware, but hardware always improves.
This obviously doesn't have any impact on those who own and trust the sender and receiver and only need to be cautious about what happens in between them. However, part of the desire for device independent security is that you can use public infrastructure without trusting it and still be certain that your communication is secure. i.e. If quantum networks replace/augment classical networks, can you trust them without controlling them? This work suggests that dream may be more difficult to achieve that previously thought, although the jury is most assuredly still out.
Isn't that everyone? Quantum crypto does nothing for authentication as far as I'm aware, so you still need to identify your recipient by some method. It requires hardware as far as I'm aware, so you still need to trust the sending and receiving hardware. Which leaves you with just the medium of transmission; if it's crypto you're trusting, the medium doesn't matter. If it's quantum effects for communicating, the only trick I'm aware of lets quantum-crypto-communication detect observers, which this 'scuppering' has no effect on.
The Technology Review article is confusing, but I can try to summarize.
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.
>"In short, the problem is that an adversary can program devices to store data in one protocol and leak it in subsequent protocols, in ways that are hard or impossible to counter if the devices are reused," say Barrett and co.
You mean, if you store the encryption key and later reveal it to outside sources, your secure communication is no longer secure? SHOCK AND AWE.
It's complete fluff that has nothing to do with quantum cryptography, just the intrinsic chain-of-trust of whatever hardware you're using. If something you're using is untrustworthy, the whole chain is - this is not a new discovery.
i don't understand how it is not susceptible to MITM attacks. how do you know you know the thing at the other end is really who you want to talk to without using some kind of preshared key? maybe an eavesdropper can't view the conversation between you and the other end but that doesn't matter if someone can easily pretend to be the other end.
Both standard quantum key distribution (QKD) and device-independent quantum key distribution schemes assume that the two parties share an authenticated classical channel. Without authentication, of course you cannot prevent man-in-the-middle attacks.
Authentication can be established using a shared secret (which is why purists sometimes refer to QKD as a key expansion protocol). Or, it can be established using signatures and certificate authorities. It is worth pointing out that man-in-the-middle (MITM) attacks must be made online; if you break a signature scheme a year after the QKD protocol finishes, it does not compromise the key.
It's possible to structure "quantum communication" (meaning passing qubits back and forth, basically) so that if someone in the middle reads them at all, the recipient is aware of it. It's not really possible to prevent the interception but it is possible always to detect it, at least in theory.
As far as I understand it (which isn't too far), quantum bits are physical things. So only the person who has the qubits can see the key exchange. As long as the qubits are physically safe in the hands of the person you want to talk to (admittedly a big if), there can't be a MITM attack.
If I buy two 5-bay DROBOs, 10 2 TB HDs, and a hardware random number generator, I could make a multi-TB One Time Pad, and copy it onto the second DROBO.
I keep DROBO one, and physically carry DROBO two to my intended recipient.
What are the problems with this?
It's cheap. It's as secure as any communication could possibly be. It provides for a whole lot of communication, with relatively little physical effort.
The problem with this is that it is unlikely to be in practical terms better than using two slips of paper to write down a 256 bit random number and using that to establish a long-lived AES-256-CTR session.
(This is without getting into the fact that a single keystream is not a secure message exchange protocol, and that conventional cryptography has well-tested ways of linking confidentiality secrets to integrity secrets and of marshalling and canonicalizing messages; I'm just answering your question on its own terms).
None of this has much to do with QC, by the way; as I understand it, QC replaces conventional number-theoretic public key crypto, not block and stream ciphers.
> a single keystream is not a secure message exchange protocol
I have to build protocols around making sure to not re-use parts of my One Time Pad. Around making sure that I validate messages. Asking for a re-send of a message. Destroy the One Time Pad because it's been compromised, etc.
But at it's core, using a One Time Pad is a secure message exchange protocol. I'm surprised to see you contradict that.
> and that conventional cryptography has well-tested ways of linking confidentiality secrets to integrity secrets and of marshalling and canonicalizing messages
I'm sorry - I don't know what you mean. Can you explain it to me more simply?
Cryptotext = Plaintext XOR OneTimePad.
Plaintext = Cryptotext XOR OneTimePad.
As I said, I have a lot of work to do to handle my One Time Pad... But the fundamental mathematics are secure. And you seem to be saying they are not. What do you mean?
The difference between a stream of bytes and a "message" is crucial, and if you don't understand it, the best reason you shouldn't do your Drobo OTP scheme is that you don't understand crypto well enough to implement any cryptosystem. Just use TLS.
(I don't mean to be offensive. I don't understand bioinformatics, for instance, and probably shouldn't build mission critical things that rely on it.)
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 weaknesses, inherent in the implementation of any security system.
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 conversation ends with a no- less- fatally- flawed system and a designer who is perversely more confident.
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.)
You can't prove that you can trust the carrier. And with trust I not only mean that the carrier has good intentions but also that the carrier is physically unable to do any mistakes.
Also you can't prove that someone doesn't sniff the traffic when you copy it to your second DROBO and you can't prove that none of the drives have been copied afterwards.
Not saying that your approach isn't "secure enough" (I'd guess that's what they do on submarines?), but compared to (the theory of) quantum cryptography it has many flaws.
I said that I physically carry DROBO two to my intended recipient. I can trust myself.
> Also you can't prove that someone doesn't sniff the traffic when you copy it to your second DROBO and you can't prove that none of the drives have been copied afterwards.
There is no such thing as secure communication. Copying data from one DROBO to another DROBO is about as secure as I could possibly imagine.
Physical security is a failure point in any system. As much as I can trust my sending location, and my receiving location, I can trust this system.
> compared to (the theory of) quantum cryptography it has many flaws.
Compared to quantum cryptography:
I can't prove that I trust the person who set up the quantum cryptography system.
I can't prove that someone doesn't sniff my connection to my quantum key system. I can't prove that someone doesn't sniff the data coming out on the receiving end.
I think this all boils down to physical security - which is a problem in any secure communication system.
And I think my two DROBO, ten HD, one hardware random number generator, one round-trip plane ticket, system is about - mmm - 4 to 6 orders of magnitude cheaper.
True, if I'm allowed to treat the quantum crypto system as a black box mirroring the DROBOs should be considered a black box as well.
But can you trust yourself to not take a large enough bribe?
What if someone hold someone special in hostage?
If you only have to convince yourself (quite limiting scenario) I see no, major, problem with your setup. This of course assuming you have eye-contact with the DROBO at all times etc. etc.
Most scenarios however you can't have as much trust in the carrier as you have in yourself.
But I agree. When reading quantum cryptography and its issues I often get the feeling that its all a bit silly. But I totally get the motivation about it, it's extremely enticing. However, I see why some likes to claim that quantum cryptography is just a way for physicists to get paid :P
But there seems to be a market for it and I have no idea how far it can go.
I know it's right up there with the "Caesar Cipher" on the cuteness sale, but the "One Time Pad" shouldn't even be considered cryptography. The only thing it does is shift the secret in time, against a passive attacker.
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 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.
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.
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.
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.
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).
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.
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.
1. The general pathology when people focus on 'One Time Pads' is that they're blinded by the 'absolute security' of that one primitive, and don't think about the security properties of everything else. Breaking your hash function allows a plaintext-knowing attacker to rewrite a message, which is considered a break of your entire system. In other words, your system is only as secure as your hash function.
2. Since the general security of a system is contingent upon its easiest attack (even if that attack is somehow 'rarer'), you might as well use that same hash function to create a stream cipher and once again avoid the huge OTP. (which is why it won't be taken seriously)
3. Security of actual cryptosystems comes from widespread implementation, study, and abuse. While your system may indeed have stronger confidentiality properties, it most likely will have undetected implementation errors due to it not being widely scrutinized.
4. I think the meat of your argument is that BKD (backpack key distribution) is comparable to QKD. I do agree that your comparison is appropriate, but think it says more about QKD than BKD. Quantum key distribution still relies on classical algorithms for authenticating the classical channel (some kind of MAC), and today's QKD products even rely on classical block ciphers, as the QKD-produced keys are quite small.
5. I see no benefits to QKD in general. It only works between prearranged (and physically connected!) pairs of parties. Reimplementing the Internet with QKD means the links are secure, but ISPs still see everything. If quantum computing really does ruin the RSA and DLOG parties, there's certainly other public key algorithms.
That's interesting. I didn't know that a system was considered broken if, knowing plaintext (and breaking a hash function) allows an attacker to rewrite a message. Probably pretty basic stuff to you.
Different kinds of attacks often play off each other, so that a small amount of known plaintext allows you to modify the decrypted plaintext of a message in ways that will reveal more plaintext.
So, for instance, a CBC padding oracle is an attack that allows you to decrypt messages byte-by-byte --- but it's stopped entirely by a proper MAC on the message.
If either side is compromised it is difficult to reissue (e.g. if they are undercover in another country).
The beauty of public keys is that they can be revoked and the other side can use your new key without you having to transport/transmit a private key in peril.
(Disclosure: haven't bothered to read the arXicle.)