Live data from Hacker News

Towards Sequoia OpenPGP v1.0

sequoia-pgp.org

41–50 of 62 posts

Re: Towards Sequoia OpenPGP v1.0

#41
post #3

IMO, encrypted e-mail is a dead end. Latacora has a good blog post about it that I highly recommend: https://latacora.micro.blog/2020/02/19/stop-using-encrypted....

I wrote an actual piece about PGP:

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

I stand by what I wrote in this post as well, but it's not a good first read for people surprised that cryptographers hate PGP.

Re: Towards Sequoia OpenPGP v1.0

#42
post #41
post #3

IMO, encrypted e-mail is a dead end. Latacora has a good blog post about it that I highly recommend: https://latacora.micro.blog/2020/02/19/stop-using-encrypted....

I wrote an actual piece about PGP: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html I stand by what I wrote in this post as well, but it's not a good first read for people surprised that cryptographers hate PGP.

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.

Re: Towards Sequoia OpenPGP v1.0

#43
post #30

Earlier quoted context omitted.

He's talking about giving their public key, not the private key that has to remain on the user's device(s) under all circumstances.

The private key is stored in localStorage, but this is not the user's "real" private key which they might use for email, but a temporary device key, which can then be vouched either by admin or by user.

I'm not understanding how this works, then. Are you using the user's private key to somehow derive temporary device keys?

Re: Towards Sequoia OpenPGP v1.0

#44
post #8

Having an alternative implementation to GnuPG is a pretty important. Although many would argue against the use of PGP encryption for many use cases such as email, there are other use cases where PGP's ideas have no replacement. For a specific example take signing git commits. Even fossil scm delegates this task to pgp. Personally keybase is the only project that may provide some form of alternative, but they do so by…

I'm using OpenPGP.js for drop-in decentralized client-side authentication for my web-based message board. This has several benefits, which includes giving technically-savvy users to do their own key generation and message signing using whatever tools they prefer, using one of the most widely used encryption/signing standards in existence. Meanwhile, non-technical users can create a new profile with literally one clic…

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

Re: Towards Sequoia OpenPGP v1.0

#45
post #26
post #16

Earlier quoted context omitted.

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'…

To be honest even PGP signing has some issues: it's not clear what does it mean to sign a commit and there is plenty of misuse of that (see [0], `git push --signed` solves some of these issues). Git patch workflow doesn't support signed commits and some kernel devs explore alternative ways of signing [1]. [0]: https://mikegerwitz.com/2012/05/a-git-horror-story-repositor... [1]: https://people.kernel.org/monsieuricon/…

I now see how my original wording is confusing. I'm using git not as the specific case here (albeit interesting) but as an example. From my understanding keybase attempts to solve some of the more questions in your first link, simply 'r/commit/post/g'. For example:

> He certainly knows his own posts, but how should others know that this “Linus Torvalds” guy who has been posting and commenting on posts is actually Linus Torvalds?

Perhaps that makes my other comments more clear?

Re: Towards Sequoia OpenPGP v1.0

#46
post #31
post #8

Having an alternative implementation to GnuPG is a pretty important. Although many would argue against the use of PGP encryption for many use cases such as email, there are other use cases where PGP's ideas have no replacement. For a specific example take signing git commits. Even fossil scm delegates this task to pgp. Personally keybase is the only project that may provide some form of alternative, but they do so by…

Git also supports S/MIME, and GitHub provides a tool to sign commits with this directly https://github.blog/changelog/2018-09-10-smime-signature-ver...

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

Re: Towards Sequoia OpenPGP v1.0

#47
post #20
post #8

Having an alternative implementation to GnuPG is a pretty important. Although many would argue against the use of PGP encryption for many use cases such as email, there are other use cases where PGP's ideas have no replacement. For a specific example take signing git commits. Even fossil scm delegates this task to pgp. Personally keybase is the only project that may provide some form of alternative, but they do so by…

First, that's a limitation of git. Second, it's easy to fake PGP: https://boats.gitlab.io/blog/post/signing-commits-without-gp... Third, we're adding support to SoloKeys to do this using a hardware token: https://github.com/solokeys/solo/issues/395#issuecomment-612... We're also collaborating with https://keys.pub/ to make "sign/verify" use cases easily usable with a GUI for everyone. So I'd say there's hope?

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

Re: Towards Sequoia OpenPGP v1.0

#48
post #6

Earlier quoted context omitted.

Hmm, I don't really see any really convincing points, or workable alternatives that your linked article provides. Nevertheless I would like to read more about this claim: > It [PGP] was designed in the 1990s, and in the 20 years since it became popular, cryptography has advanced in ways that PGP has not kept up with. So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without…

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

That is not in fact a good description of EFail, which was indeed caused by a failure both of the PGP protocol and of GPG, its reference implementation.

Re: Towards Sequoia OpenPGP v1.0

#49
Here's the command line documentation:

https://docs.sequoia-pgp.org/sq/index.html

I have to admit that it looks more digestible than gpg's. It seems it's still missing a way to manage OpenPGP smartcards like Yubikeys. Also, I can't see a way to manage an arbitrary set of subkeys for a given primary key.

I'm really happy to see an alternative to GnuPG, though. This looks promising.

Re: Towards Sequoia OpenPGP v1.0

#50
As someone who has been trying to use this library but haven't had the time to finish build integration to cross compile for all of my target platforms, I really wish it weren't using nettle, particularly as it is also using openssl :(. Does rust not have useful cryptography libraries yet? Or couldn't it just openssl?
Post reply on HN