Towards Sequoia OpenPGP v1.0 (opens in new tab)

You should definitely not be encouraging your users to give their private keys to js on other sites, that’s just as bad (or maybe worse) as encouraging them to reuse passwords.

That sounds really interesting, would you be willing to share a link to the message board so I can see what your account creation process looks like? The other most common place I've seen PGP used as an account identifier are in darknet markets, where users are warned to use a GPG binary from a trusted source and against whatever serverside system that was built for ease of UX.

Related to the issue that swiley mentions, I'm not really sold that attributing the user to a string of digits is good UX, whereas I like how keybase puts a distinction between identity and secrets.

A "keybase proof" simply shows that at some point a singular identity had access to a multitude of accounts, but has no guarantees about the current account holders. This may seem like a negative but shifting the responsibility onto account holders to protect their secrets is more reasonable than assigning the identity of an individual to a single, long term secret [0] or deal with key transition.

[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#...

S/MIME and PGP share the same basic problem: they provide a container for the basic public-key crypto primitives (signing and encryption) together with an identification of the public key and leave it at that. Throw on top of that tools that are usually uninterested in actually thinking about how policy decisions affect cryptographic security and you have an example of security theater.

I've seen similar projects that use S/MIME for identity management, but as seen from the README of the tool[0] the benefits of PGP's web of trust can be seen in unstructured environments. Online identities are perhaps the most unstructured environment, where aliases and personas are the norm.

[0]: https://github.com/github/smimesign

I'm not endorsing keybase, in fact I have much of the same criticisms as you probably do.

The fact is unlike many PGP replacements most don't attempt to solve similar ideas as the "web of trust". For those that I know do, the cryptocurrency/tokens one's don't even consider backwards compatability. As far as I know keybase are the only ones that embrace PGP and are therefore backwards compatible with git, fossil, etc's commit signing.

It may be ignorance but I don't see linux, git or any other software project that "needs" both version control and verifiable commits moving from PGP signing to something else, but rather PGP signing dying out with the rise of git platforms like github, gitlab, etc. If you squint you can see that keybase provides some form of alternative.

Your linked post is not about faking PGP, it is about replacing PGP with his own implementation which supports only a subset of the PGP standard, the subset necessary to properly sign git commits.

I've not made myself very clear in the comment, but git and fossil scm are simply examples that delegate issues of trust to PGP's web of trust. Hardware keys are more secure, but from my understanding still stuffer from the same issue PGP does - a physical device is not an identity. keys.pub looks very interesting, but it seems that like keybase it doesn't address everyone's concerns[0].

From a technical perspective if keys.pub exists there's no reason that the proof process could occur at a layer above git rather than within git in some form of "social proof sidechain"-like structure.

I'm definitely going to keep an eye on key.pub, once they've addressed some of their coming soon items they'll be a very nice contender to keybase.

[0]: https://news.ycombinator.com/item?id=22994650

>Second, it's easy to fake PGP:

An odd way to put it, but yes, the simplicity of the OpenPGP standard is one of its greatest strengths. Somehow the standard has resisted just a ton of stuff that would be pointless over the long term over a great many years.

And yet encrypted instant messaging would have the same pitfalls if the platforms where federated like email is.

It only works well and seamlessly because it works within a single provider.

Although I agree with your point, both the article and your comment suffer from different use cases + threat models.

I'd agree that there are no real alternatives to (regular) mail and email where longer form asynchronous communication can occur without the expectation of an instant reply.

Unfortunately when it comes to this form of communication the reality is that there aren't any widely used alternatives that don't leak as much metadata as email.

My best guess is that they really meant EFAIL but didn't want to actually mention it because EFAIL had nothing to do with any weakness in the OpenPGP standard or the GnuPG implementation. Instead it was a HTML email horror story where someone figured out how to forward entire decrypted messages using image links.

So just more pointless anti-PGP innuendo...

It is talking about things like efail.

Perhaps I should have linked to both essays. People should read them both :) The reason I linked to the other one was that encrypted mails is the first use case listed on the Sequoia site.

The writer of the article wrote another one that is linked where he criticises other uses of PGP[0].

[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

Agreed, can be used for signing git and other stuff. PGP isn't only about encryption, it's also about authentication and integrity.