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.
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.