One time pads are rarely useful: The key is as big as the data, so you need a secure channel to transmit the key. If you had that channel, why not just transmit the data over it?
Your mistake here is failing to consider that sharing an entropy pool does not (and in fact should not, it must be shared out-of-band anyway) need to be real time. Fundamentally, OTPs involve leveraging physical security and fleeting points of physical contact to create a pre-shared perfectly secure future communication channel. Ie., two people meet up an exchange a USB stick (or HDD), then consume the entropy pool over time. These days that could mean trivially having a pool of hundreds of gigabytes to terabytes, which equates to tens of thousands of hours of high quality voice communications, ludicrous amounts of plain text, etc, and that's assuming direct consumption. If instead it's used just for symmetrical session keys then from a human perspective it'll last forever (can burn through thousands of 512-bit keys an hour for an entire lifetime and still be fine).
The issues with OTP include that it doesn't provide authentication, it doesn't scale, pure point-to-point, etc., and that in the end the benefits it offers just don't matter in general right now vs the costs and disadvantages. There's no reason in general not just use a decent pre-shared self-gen cert, PKI or WoT key system instead. OTP applies best to any organization that can already handle physical security. Basically, if an organization moves weapons, money, or drugs around securely then it could move entropy too, so governments, militaries, banks, organized crime and the like. But for anyone to bother all existing crypto would have to be utterly broken, otherwise it's superior to just use standard crypto.
The primary issue is that through misuse it degrades almost instantly from unbreakable to "little better than ROT13". And, it still appears secure to the hapless user.
>The primary issue is that through misuse it degrades almost instantly from unbreakable to "little better than ROT13". And, it still appears secure to the hapless user.
Please explain how this does not apply identically to every form of encryption, particularly as we have directly seen vulnerability after vulnerability. That implementation matters goes without saying in these discussions, but if you want to go there then in that respect OTP is fundamentally much simpler and easier to get right then public-key crypto. Generating decent random noise, storing it in an ordered way, then deleting it automatically after use are comparatively straight forward operations to automate. Using each bit is just a matter of an XOR operation and that's it.
So I disagree with you that technical challenges are in any way even remotely the "primary issue" when it comes to OTP. If there was a need for it it'd be rapidly adopted. But outside of certain very niche scenarios, maybe, there simply isn't any need for it, nor will there be in the foreseeable future.
If I use the same AES key to encrypt two messages my communications are still mostly secure. Specifically, there's no known way to recover the key and attack all my other messages.
Versus if I use the same OTP twice my security is automatically shot and any other communication with the OTP is now also as good as leaked. Worse, context can then let much more of the key material be leaked than just the shared portion.
Even if used correctly, you've first got to create the OTP. Any mistake in generating your OTP means you can have a predictable pad and not know it. If you're trying to gather strong entropy you can know your lava lamps (/ geiger counter / etc) sources are random and be brought down by a bad camera driver.
Also, any methods to strengthen your OTP (ie, hash multiple streams together) are the very tools that you're avoiding by using an OTP. If you trust them you should just use them.
