This is great news! I always wondered why this was not possible and I’m glad to hear that it now is. I must say I’m somewhat uncomfortable with using Github as a trusted third party. I don’t see how we can do away with the web of trust if we really want a trustworthy cryptographic ecosystem.
The original idea was that you’d upload your GPG public keys (and later SSH keys), and then, rather than dealing with the shitshow that is GPG key signing parties, you could attest your Keybase account publicly on various social media (Twitter, Hacker News, GitHub, your personal sites, etc.), giving extremely high confidence, in very public fora, that a given GPG key belonged to who you wanted it to. Problem is, that’s not a business, so I always knew it was going to be a limited engagement before they attempted to jump the shark and instead landed in its gullet.
Keybase helped users prove which social media accounts and domains they own. This nicely reused webs-of-trust and identities that people already know.
For example, you prove your identity on Lobsters, Twitter, GitHub and GitLab. Each site could individually perform a MITM attack and show a false key. But it’s extremely unlikely that all of them would collaborate to fake the same identity. So when the same identity/key is proven on all of them at once, it’s a quadratically higher level of assurance that it’s a valid key and that’s the same person.
It is, but it misses the real problem: Revocation.
The biggest weakness of SSH is that it does not have a good revocation story. If an SSH key is compromised, revoking it from the authorized_keys file on every machine it’s used on is a massive pain, but just about tractable. This is why using SSH keys to sign things is a terrible idea and why signing certificates are signing certificates, not keys: they carry things like a valid date range and the location of a revocation list in-band.
I did https://sshign.tcardenas.me/ a while back, to make this easy, especially for verification (as signers probably can manage themselves in the CLI anyway).
One question I have: what does signing a file actually mean? For example, does it mean “I created this file” or “I confirm this file does not have a backdoor”, or “I confirm this is an official release”? Without defined semantics and additional metadata (or standardised formats, like software packages) , isn’t this open to cross protocol attacks? It feels like the “file” namespace is too generic to be useful.
More so the user experience. I use multiple yubikeys for holding the keys and every time I have to enter a pin if I pull it out to use it on another host. Sometimes pin entry will happen as a gui window, other times if I’m in tmux it’ll use an ncurses gui. Nearly every time I have to export some sort of TTY variable.
OK I was misremembering; apparently gpg-agent has a mode in which it can act as a replacement for ssh-agent, but most systems don’t work this way out of the box.
One weird use case is that we would use messages over SSH keys for account recovery at Heroku, This was many moons ago, when SSH git was the only way to push code. Account holders would lose access to their accounts, so one factor for account recovery would be to decrypt a message from us using their private key.
It was all very cool at the time but since then HTTPS git has become much more popular. I wish HTTPS client certificates were as easy to use and widespread as SSH keys.
It was all very cool at the time but since then HTTPS git has become much more popular. I wish HTTPS client certificates were as easy to use and widespread as SSH keys.
Seems kinda the opposite to me, considering GitHub massively defanged HTTPS access without a token…
At Heroku I think it largely went to HTTPS just git because the Heroku CLI set it all up by default, and almost everyone was on the CLI. Once the login to the Heroku API is completed it just uses that for git and it Just Works. You had to go out of your way to add SSH keys. You’re right on GitHub, it seems more awkward there to use HTTPS. I wonder how widespread their GUI or CLI is across their users.
This is great news! I always wondered why this was not possible and I’m glad to hear that it now is. I must say I’m somewhat uncomfortable with using Github as a trusted third party. I don’t see how we can do away with the web of trust if we really want a trustworthy cryptographic ecosystem.
Keybase had the right idea for identity verification, until they’ve jumped on a chatapp-shitcoin-aquihire death spiral ;(
I missed the Keybase hype before the spiral, what did it get right about identify verification?
The original idea was that you’d upload your GPG public keys (and later SSH keys), and then, rather than dealing with the shitshow that is GPG key signing parties, you could attest your Keybase account publicly on various social media (Twitter, Hacker News, GitHub, your personal sites, etc.), giving extremely high confidence, in very public fora, that a given GPG key belonged to who you wanted it to. Problem is, that’s not a business, so I always knew it was going to be a limited engagement before they attempted to jump the shark and instead landed in its gullet.
I always found this pretty spammy and annoying.
Keybase helped users prove which social media accounts and domains they own. This nicely reused webs-of-trust and identities that people already know.
For example, you prove your identity on Lobsters, Twitter, GitHub and GitLab. Each site could individually perform a MITM attack and show a false key. But it’s extremely unlikely that all of them would collaborate to fake the same identity. So when the same identity/key is proven on all of them at once, it’s a quadratically higher level of assurance that it’s a valid key and that’s the same person.
What about the crypto maxim that “a key should be used only for one thing”?
The article addresses this in the section “Is it safe to repurpose SSH keys?”
It is, but it misses the real problem: Revocation.
The biggest weakness of SSH is that it does not have a good revocation story. If an SSH key is compromised, revoking it from the
authorized_keysfile on every machine it’s used on is a massive pain, but just about tractable. This is why using SSH keys to sign things is a terrible idea and why signing certificates are signing certificates, not keys: they carry things like a valid date range and the location of a revocation list in-band.Good call, revocation is equally important as issuance.
I did https://sshign.tcardenas.me/ a while back, to make this easy, especially for verification (as signers probably can manage themselves in the CLI anyway).
Funnily, I wrote a tool with the same name a while ago https://git.sr.ht/~minus/sshign (incompatible with ssh’s signing though)
One question I have: what does signing a file actually mean? For example, does it mean “I created this file” or “I confirm this file does not have a backdoor”, or “I confirm this is an official release”? Without defined semantics and additional metadata (or standardised formats, like software packages) , isn’t this open to cross protocol attacks? It feels like the “file” namespace is too generic to be useful.
It means a given private key was used to sign the file. There isn’t a fundamental meaning above that.
Yeah, the
filenamespace strikes me as a mistake, though one folks have been making with pgp since forever…This is really exciting!
Really looking forward to dropping the gpg agent from my workflow
Isn’t the gpg-agent literally just the same program as ssh-agent but with a different flag?
More so the user experience. I use multiple yubikeys for holding the keys and every time I have to enter a pin if I pull it out to use it on another host. Sometimes pin entry will happen as a gui window, other times if I’m in tmux it’ll use an ncurses gui. Nearly every time I have to export some sort of TTY variable.
OK I was misremembering; apparently gpg-agent has a mode in which it can act as a replacement for ssh-agent, but most systems don’t work this way out of the box.
One weird use case is that we would use messages over SSH keys for account recovery at Heroku, This was many moons ago, when SSH git was the only way to push code. Account holders would lose access to their accounts, so one factor for account recovery would be to decrypt a message from us using their private key.
It was all very cool at the time but since then HTTPS git has become much more popular. I wish HTTPS client certificates were as easy to use and widespread as SSH keys.
Seems kinda the opposite to me, considering GitHub massively defanged HTTPS access without a token…
At Heroku I think it largely went to HTTPS just git because the Heroku CLI set it all up by default, and almost everyone was on the CLI. Once the login to the Heroku API is completed it just uses that for git and it Just Works. You had to go out of your way to add SSH keys. You’re right on GitHub, it seems more awkward there to use HTTPS. I wonder how widespread their GUI or CLI is across their users.