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

The Key (K) is determined by the position in the OTP, specified by the message header.