←back to thread

Sign arbitrary data with your SSH keys

(www.agwa.name)
637 points h1x | 2 comments | 13 Nov 21 09:13 UTC | HN request time: 0.419s | source
Show context
exabrial ◴[13 Nov 21 18:54 UTC] No.29212231[source]▶
Great idea: easy key distribution and management. Like most p2p ideas, PGP also sucked at this.

Terrifying idea: trusting a third party to maintain the metadata about a key and who's identity it represents.

PGP absolutely got this part right: if you modify the contents of the metadata, the hash changes. Basically, if a private key were to point to Myself, and I distributed it widely, then lost it... an attacker who recovered said key could _transparently_ change the identity of the key and we'd have no record of who was actually correct. And lets not pretend that a government couldn't coerce Github to add an ssh identity to your account (it is owned by Microsoft now, and they have DOD contracts to fulfill).

Keybase solved both these issues: easy and intuitive, transparent proofs, along with the rigidity of metadata with pgp keys: if a key owner changes, the pgp key mutates.

replies(3): >>29212315 #>>29212532 #>>29212620 #
cassonmars ◴[13 Nov 21 19:02 UTC] No.29212315[source]▶
> if a key owner changes, the pgp key mutates.

How does Keybase address this problem completely? If an attacker gains possession of a key, they don’t have to change ownership, they just assume the role of that user. NB: I know they could feasibly only do this once before the key is considered burned by detection from the original user, so I’m somewhat lost here. Presumably you could mean that revocation of a known stolen key would be easy to point to, but any PKI can handle this.

Edit: I’m aware of Keybase itself doing per-device salts, but under a sophisticated attack, I don’t see a workaround here unless they’re doing some multi-party signing process with authorization against the Keybase server who acts as a second party, but even then, a sophisticated attacker who has control of the user’s machine impersonating someone would still be able to circumvent this.

replies(1): >>29212346 #
1. exabrial ◴[13 Nov 21 19:06 UTC] No.29212346[source]▶
If you have a PGP key bound to your email: yeehaw@woot.com and you change the email in the key to: haha@yougotserved.com it produces a definitive hash change, while the underlying key material doesn't change.

Contrast that to an ssh key, which has no bound metadata.

And to your point, both systems in isolation are useless. But the first, combined with proofs and a distribution point like keybase, form a complete system. The second however, ALWAYS relies on a trusted party not doing bad things.

replies(1): >>29212420 #
2. cassonmars ◴[13 Nov 21 19:17 UTC] No.29212420[source]▶
Right, I guess what I was more critical of wasn’t a hash confirmation of associated data — it’s more the trivial bypass of this when the key is compromised in the first place. Theoretically, a user doesn’t export their key, or if they do, it’s under a tightly controlled manner which limits surface area for exposure to only the source and destination. So in this scenario, the only way a private key is exposed is if one of the user’s devices is compromised, in which case the promise of associated data is meaningless.