Live data from Hacker News

Towards Sequoia OpenPGP v1.0

sequoia-pgp.org

31–40 of 62 posts

Re: Towards Sequoia OpenPGP v1.0

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

Re: Towards Sequoia OpenPGP v1.0

#32
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…

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

Re: Towards Sequoia OpenPGP v1.0

#33
post #10
post #9

Earlier quoted context omitted.

PGP is used for more than just email

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

Some of those issues are just properties of GPG and could be fixed by an alternative implementation, while others look inherent to the standard.

Re: Towards Sequoia OpenPGP v1.0

#34
post #19

Earlier quoted context omitted.

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.

I'm generating the keys in-browser for device-specific keys. I am not asking the users to provide their existing private keys, but I am storing the device keys in localStorage, because, where else?

The advanced users can then use their existing PGP keys to sign the device keys.

But this is not necessary in every environment, because in some situations, e.g. casual chat or internal boards, you don't need that kind of extended security, and temporary device keys, perhaps vouched by the operator, are sufficient.

Re: Towards Sequoia OpenPGP v1.0

#35
post #30
post #19

Earlier quoted context omitted.

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.

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.

Re: Towards Sequoia OpenPGP v1.0

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

That's a good point... Perhaps a better solution is for them to be able to sign the public keys from the other sites to connect their profiles that way.

Thank you for your feedback. I can see now how a malicious system operator could steal the user's private key by modifying the JS.

Re: Towards Sequoia OpenPGP v1.0

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

Whenever someone criticizes email encryption they fail to provide an actual replacement. Encrypted instant messaging is an alternative, but it's not a replacement.

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.

Re: Towards Sequoia OpenPGP v1.0

#38
post #9
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....

PGP is used for more than just email

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

Re: Towards Sequoia OpenPGP v1.0

#39
post #37

Earlier quoted context omitted.

Whenever someone criticizes email encryption they fail to provide an actual replacement. Encrypted instant messaging is an alternative, but it's not a replacement.

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.

What about OMEMO?

Re: Towards Sequoia OpenPGP v1.0

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

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