Live data from Hacker News

Towards Sequoia OpenPGP v1.0

sequoia-pgp.org

21–30 of 62 posts

Re: Towards Sequoia OpenPGP v1.0

#21
post #19

Earlier quoted context omitted.

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…

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.

> encouraging your users to give their private keys

I read it twice and still can't find the place where it was mentioned this to be the case.

Re: Towards Sequoia OpenPGP v1.0

#22
I still use PGP to encrypt files with secrets in them that I am sending to a known source, and I know it's still the base encryption for a few well known file servers. A new player in the market is welcomed.

Re: Towards Sequoia OpenPGP v1.0

#25

I still use PGP to encrypt files with secrets in them that I am sending to a known source, and I know it's still the base encryption for a few well known file servers. A new player in the market is welcomed.

Keybase's "Crypto tools" tab can do this, with "known destination" determined via social proof.

https://keys.pub is a re-implementation of this use case without the messenger/cryptocurrency baggage that some dislike about Keybase.

Re: Towards Sequoia OpenPGP v1.0

#26
post #16
post #14

Earlier quoted context omitted.

> Personally keybase is the only project that may provide some form of alternative, but they do so by supporting pgp. Why keybase? Reading their crypto page ( https://keybase.io/blog/crypto ) leaves the impression that they took PGP and embrace-extend-extinguished it...

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/introducing-b4-and-pa...

By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?

Re: Towards Sequoia OpenPGP v1.0

#27
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?

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

Re: Towards Sequoia OpenPGP v1.0

#28
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?

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.

Re: Towards Sequoia OpenPGP v1.0

#29
post #6
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....

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…

It is talking about things like efail.

Re: Towards Sequoia OpenPGP v1.0

#30
post #19

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN