Very few users can run their own web servers. We used to deploy GoToMyPC for users; it was reliable, performed well, platform independent (including mobile), and secure. I expect it still is.
When the new OS or other new tech came out, GoToMyPC handled any compatibility issues; we didn't have to worry. No matter what the user's remote computer was, it worked (as long as there was an Internet connection). The security was good too: End-to-end encryption, optional one time pads, and even details like blanking the screen of the host machine so that someone in the room with the host couldn't monitor what the user was doing.
We stopped using it because we didn't need it any more, but we were happy customers for many years until that point.
Any good reason why this wouldn't be the default? Speed + key exchange transmissions, maybe?
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.
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.
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.
It costs time and effort for the users, not only to execute it but to learn it, troubleshoot problems, etc. It would drive many users away; in a business environment especially, that time and effort are rare and precious.
One of the main reasons that things like gotomypc and teamviewer have been successful in the market is the huge number of people who don't know how to/don't care to take the time to set up an SSH tunneled setup, and want something to "just work" through NAT.
My setup looks something like this, with public/private key SSH auth. Copied and pasted from my notes, hostnames and IP addresses redacted:
-------
I have a static /30 and forward port 445 on the external side of my home router, through the NAT to port 22 on the workstation PC in my rfc1918 IP space.
workstationhostname.domainname.org normally has vnc session listening on port 5901 localhost only, spawned with:
vnc4server -geometry 1920x1200 -localhost
This is for use with an SSH tunnel coming from hostname.ofmy.static.slash30.org:445 through NAT to workstationname.rfc1918.ip.address port 22
To access from the outside world, on the client, do the following:
ssh -v -L 5901:localhost:5901 -N -f -l myusername -p 445 hostname.ofmy.static.slash30.org
use client system's vnc client software to connect to 127.0.0.1:5901
ssh -v -L 5901:localhost:5901 -N -f -l myusername -p 22 workstationname.rfc1918.ip.address
use client system's vnc client software to connect to 127.0.0.1:5901Go to System -> Remote Desktop Connections and check the box to enable incoming connections.
On your router, forward port 3389 to the machine you want to access.
On any client device running Windows (linux/mac can use FreeRDP, for which there are numerous wrappers) connect to your home's Public IP, and log in with your computer's usual username and password.
For the average home user this is all the setup that's needed, and it doesn't involve handing over your computer's security to a third-party company that is now a giant target for these sorts of attacks. :)
I think the big advantage that LogMeIn and GoToMyPC have in the casual realm though is their simplicity. In particular, they entirely dodge the need for the user to know anything technical at all, including port forwarding on the router, which is the bigger technical hurdle here. You just install their program and it does the rest for you. Port forwarding seems like child's play to you or me, but they have a huge market in folks who didn't even know you could log into your router and change settings. Or that even know what a router is, despite owning one.
I wonder if IPVv6 would help here? Would we expect to get a static IP address for a device that can stay the same even when we're connected to different networks or via mobile data and wifi? That would mean even different network interfaces in the device would need to share the same address so I guess it still won't happen.