Sign arbitrary data with your SSH keys

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.

> 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.

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.

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.

Are there resources on the impact of Keybase being bought by Zoom? Zoom is out of question too because they discourage e2e and darkpattern you into installing their software despite browser compatibility and because they darkpattern you into giving cam/mic access just to listen to a broadcast-only session even if unnecessary. They place their own controlled device toggles as source of truth instead of those by the browser UI and fail in weird ways if you toggle in-browser. (Same for almost all other similar software as well)

I tossed them without a second thought after they annoyed me with Stellar. Nobody uses Stellar if they dont have a hidden incentive. It always had a huge forced marketing vibe.

Is there some sucessor to keybase?

(Motivation disclaimer: I want to dump on Keybase because in the end, even with flawless crypto at first, those organizations always erode the good things down to centralized with platform control again.)

> PGP absolutely got this part right

Lol no.

There is no mechanism to invalidate keys by the domain owner, while it uses email as one of the core identifiers.

I purchased a cool domain, which had PGP users who published their keys to various key servers.

Their keys have no expiration, while I'm in control of the domain...

PGP was good, 30 years ago. But technology has evolved, along with the understanding of the problem.

I made a reply about SSHFP records (https://news.ycombinator.com/item?id=29212552), to push server keys in the DNS: that + DNSSEC means you remove the problem of initial trust (deciding to add a server to your known_host on the first connections)

Now imagine if something like MX records could also contain SSH keys for the mail users: you'd solve the problem of mail encryption on a global level.

People who want to send me encrypted mail could ask my server for my key, DNSSEC would prevent tempering with that, and if I lose access to the domain, there would be no issue with stale keys from old PGP directories.

As for scalability issues, DNS is perfectly done (with caching, etc) to handle that easily.

Like you, I could say "SSH got this part right" - but no. Again, technology has evolved.

The "only" problem would be correlation attacks, and I think that's a big one, in the age of surveillance.

Ideally, we'd have something like bitcoin key-derivation from a seed key, where you'd have:

- a key you publish to receive encrypted email,

- derived public keys, one per server, so that you do not risk correlation attacks

This is a great article, because it looks at the ubiquity of SSH keys, and how the technology is better than PGP keys, to advance the problem - say by signing git commits and tags.

I hope we'll also use the advances from other technologies.

> Now imagine if something like MX records could also contain SSH keys for the mail users

Unfortunately that leads to this: now imagine said MX servers were under whatever political party you oppose.

> Unfortunately that leads to this: now imagine said MX servers were under whatever political party you oppose.

Hmm, what could I do?

Maybe change my MX records to move from mailgun to postmark or any other mail provider? Or self host?

But that's if we assume the key servers would have to be the same as the MX servers, because of some technological limitations.

Alternatively, it could be done like SSHFP where SSHFP records exist independently from the CNAME records: then the problem disappear, as you as the domain owner can delegate the MX part to one company, while only entrusting yourself with the publication of the public keys.

If you mean "but what about gmail users" - if gmail servers are under whatever political party you oppose, you've got a much bigger problem, and I don't think there can be a technological solution.

Here is an example of how to change the email address associated with a OpenPGP identity on a key server:

* https://coderwall.com/p/tx_1-g/gpg-change-email-for-key-in-p...

If you want to invalidate the identity entirely you just upload the revocation certificate.

> Is there some sucessor to keybase?

Depends on the use case. E.g. for raw identity proofs https://keyoxide.org works well but it's not as straightforward to use as Keybase.

I don't think you understand: the key is not mine, it's from the previous users of that domain, so I can't apply these instructions as I don't have their private keys!

To make things worse, there is no mechanism to let the key server know that the emails associated with these keys are invalid.

And I have tried my best to get in touch with maintainers to explain the stupidity of this situation, but there is apparently no way besides revocation certificates to deprecate or delete a key. Or, if I give a less generous interpretation, maybe they want to keep pretending that PGP still has a lot of users?

So a known bad key is associated with my domain, with no way to fix that - except maybe waiting for PGP key servers to die and be finally replaced by something better.

This is why I call that an outdated technology. I'm sure it was good 30 years ago, but it should have evolved.