The OTP is more a theoretical construction than a real world construction. The OTP suffers from three core problems:
- Key Generation.
- Key Distribution.
- Key Destruction.
Let's deal with each one in turn.
Key Generation
Key generation is surprisingly difficult. In order to get the full security proof for the OTP, you need to each bit to be independent of every other bit and for there to be no bias whatsoever in the output.
Now practically every hardware RNG you're going to get does not fufil this in practice. They almost always run the bits through a hash function or some sort of entropy extraction routine. However, these routines do not carry a security proof that they preserve the underlying independent non-bias nature of the bits passed to them.
It's quite possible that if you the entropy extraction routine over enough bits, that a very small bias would be observed. However, any such bias, no matter how small would destroy the OTP security proof.
So you need to design your own RNG using only de-biasing techniques that maintain the security proof. Worse, you need to build an RNG with no detectable bias whatsoever over gigabits of output.
Key Distribution
Key distribution is a pain because the key has to be as long as the message. This immediately raises the question of why bother with encryption if you already have a secure channel of transmitting the key. Even with this massive key you haven't authenticated the cipher-text! You need provisions for that too.
This limits the OTP to scenarios where you want to time-shift a secure channel. It works okay in scenarios like the following. If Alice lives in Hong Kong and Bob lives in New York, they can meet twice a year and exchange a gigabyte or two of pad and be on their way.
Even if you're using QKD you've just moved the problem elsewhere. The problem now moves from a key distribution problem to an engineering problem. You've got to make a QKD device that is 100% reliable, doesn't have any side channel attacks, and is not susceptible to induced errors. Such as slightly overpowering/underpowering device to get duplicate photons, shinning a laser at the device to subtly break it or some other error inducing attack.
You've got many of the same problems of hardware quality as you had with the PRG. Good luck with that!
Key Destruction
Once you've used the key you have to make sure it is properly destroyed in both places. This is again more tricky than it seems at first.
If you don't do this properly and you use the key-stream twice, you have no security at all. If the program that manages the pad for you suffers some sort of error and fails to delete the used portion of the pad then re-use becomes quite likely.
Worse, because the pad is the same length as the message there's quite a lot of key stream to leak. This can leak in a number of ways. Parts of the key stream might have been paged to disk, for example, during encryption/decryption process.
An attacker could then decipher parts of your ciphertext by simply XORing bytes from your recovered hard-drive against the ciphertext.
Conclusion
The reason that the OTP isn't really fielded is that despite its strong security proof, the practical considerations around it actually render it insecure.
This is actually quite common in cryptography. Things with strong security proofs tend to be unworkable.
For every section of my reply, there is a documented case where precisely the problem I've raised has led to OTP messages being compromised.
OTPs are really hard to use properly and are typically less secure overall than a conventional scheme.
Small secrets, by virtue of them being small, are less likely to be leaked, easier to generate, easier to destroy and easier to transmit. All of these properties make them more secure.
