Comment by m0dest | Hacker News Reader

Comment by m0dest | Hacker News Reader

Parent Full thread

It’d probably be some new PKI on top of SSH where your private key would be held in escrow by an identity provider. e.g. Your username is your email address, and your email provider retains your key pair. It’d probably be portrayed as an improved key management solution that allows more frequent key rotations and revocations. Might even start with being required for government projects, resulting in supported implementations by cloud providers that want lucrative government contracts. Then they just wait for a crisis opportunity like a cyberattack to force ISPs to block non-PKI-based SSH traffic in the name of national security.

And the largest and most paranoid companies that host their own mail and authentication services on-perm would probably be allowed to use those. But most everyone else is left doing key escrow with Google and O365 for their work and personal accounts...

Forced key escrow was actually floated before, when I was a kid in the late 80's/early 90's.

Even as a child it seemed like a terrible, dangerous idea.

That's the epitome of the 'what could possibly go wrong' meme.

But think of the children! Do you want to help the terrorists? What's so bad that you want to hide it?

America is looking more and more like a Soviet style dictatorship every day. The United States' propaganda machine is so well tuned that they don't need to physically oppress us with secret police on every block. We oppress ourselves.

Given the trade wars, would the US be ok if China were to hold onto American company private keys so they can "monitor for lawful activity" of Chinese users?

Let that sink in and show that the government arguments are not workable in the slightest.

It could happen that the US blocks services from China the same way China blocks services from the US.

Oh well, the Internet was cool I guess.

> It’d probably be some new PKI on top of SSH where your private key would be held in escrow by an identity provider.

There's only a small problem here: the SSH private key is not used to encrypt the connection. It's used solely to authenticate the connection. The key used to actually encrypt and authenticate the data is an ephemeral key derived through a Diffie-Hellman key exchange during the connection establishment. That is, having the SSH private key does not allow one to decrypt the data after the fact. The only thing having the SSH private key allows is doing a MITM attack, and since SSH does mutual authentication, the attacker would need to have the private key for both ends of the connection.

Great point. I’ll have to dream up another dystopian fate for SSH.

Reply on news.ycombinator.com