This may well be a good thing [LWN.net]

This may well be a good thing

Posted Dec 7, 2023 8:56 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

The easy solution is to have your private key hosted… which of course makes encryption rather useless.

There is no going around this, despite years and years of repeating comments like yours.

This may well be a good thing

Posted Dec 7, 2023 9:30 UTC (Thu) by elenril (subscriber, #165899) [Link] (1 responses)

Don't get me wrong, I acknowledge and accept that key management and distribution is the hard problem here that has no magical simple solution. Still, there are better and worse ways to approach this problem and gpg just seems like piles upon piles of legacy hacks and outdated assumptions. The fact that its "library" invokes the gpg binary and parses its output really speaks volumes about its architectural qualities.

This may well be a good thing

Posted Dec 7, 2023 10:06 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

You are completely moving the discussion now.

Rewriting a library to not call fork would not help users in any way.

This may well be a good thing

Posted Dec 7, 2023 11:58 UTC (Thu) by gioele (subscriber, #61675) [Link]

> Seems to me gpg is actually standing in the way of widespread email encryption by being utterly incomprehensible and unusable for non-experts. More fragmentation could mean that eventually a new toolset emerges with more of a chance at wide adoption.

Sequoia-PGP https://sequoia-pgp.org/ has taken an interesting approach:

1) reimplement OpenPGP primitives in Rust,
2) provide a simple human-oriented command line interface to most operations (sequoia-sq),
3) provide a drop-in reimplemetation of gnupg command line interface (gpg and gpgv) so that scripts and applications can continue working unchanged (sequoia-chameleon-gnupg).

Sequoia-PGP is not 100% ready to replace gnupg, but it is already at feature parity when it comes to the most common operations.

I wonder what the position of the Sequoia-PGP project is on the "schism" described in this article.

This may well be a good thing

Posted Dec 7, 2023 12:28 UTC (Thu) by dsommers (subscriber, #55274) [Link] (7 responses)

> Seems to me gpg is actually standing in the way of widespread email encryption by being utterly incomprehensible and unusable for non-experts.

That's my feeling as well. And this extends further to just the OpenPGP standard itself. GnuPG has served its purpose of making PGP widely available on lots of platforms. But it is just horrendous to use in practice. I spent too much of my last weekend to migrate new PGP subkeys to a new set of Yubikeys. The steps needed to do subkey management is just too low-level for mere mortals. And then when GnuPG ends up leaving "old status cruft" in ~/.gnupg/private-keys-v1.d which needs to be manually resolved through debugging ....

I'm grateful for what Werner Koch has managed in regards to PGP availability, but GnuPG is far from a tool inviting new users to the PGP world. The efforts Proton has done is by far more user friendly (they've even made it basically transparent for users not specifically digging up the PGP keys).

What I do hope is that the Sequoia-PGP project can end up with a more reasonable and friendly user interface. I've not been able to compile it on my RHEL-8 setup yet for some proper testing, but the documentation certainly makes it look far more inviting. https://docs.sequoia-pgp.org/sq/

If Sequoia can truly establish itself as a proper alternative PGP implementation, I believe the days of GnuPG will see the end eventually. If Werner Koch really cares for OpenPGP and wants GnuPG to survive, he certainly should be far more careful in putting up blockers like this and kicking off forks like LibrePGP. Proton is also a too large PGP consumer to be ignored (with more than 100 million users); and they will push forward for more future safe crypto implementations.

This may well be a good thing

Posted Dec 7, 2023 12:42 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"What I do hope is that the Sequoia-PGP project can end up with a more reasonable and friendly user interface. I've not been able to compile it on my RHEL-8 setup yet for some proper testing"

RPM is using it these days so it should become available in more places

https://fedoraproject.org/wiki/Changes/RpmSequoia

This may well be a good thing

Posted Dec 7, 2023 15:25 UTC (Thu) by ballombe (subscriber, #9523) [Link] (5 responses)

Is not Proton hosting the PGP keys ?

This may well be a good thing

Posted Dec 7, 2023 15:29 UTC (Thu) by dsommers (subscriber, #55274) [Link] (4 responses)

The encrypted keys are stored with Proton, yes. They are unlocked on the devices only, through the SRP (Secure Random Passwords) protocol, which never sends the plain text password over the net. All encryption and decryption happens entirely in the browser, in the mobile apps or the locally running mail bridge (for SMTP/IMAP access).

This may well be a good thing

Posted Dec 7, 2023 16:22 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

It seems Proton was the main driving factor for pledging for GCM mode which in turn required a lot of changes to the protocol to mitigate its brittleness. The reason is that the major web browsers still do not implement the faster OCB mode and it had to be implemnted in JS for that reason (cf. non-availability of SRV record queries). This is the major "chism" - I explained over at https://libregpg.org that proliferation of algorithms is a bad for security and that OpenPGP tried to avoid that as much as possible.

BTW, One good thing with the delays is that meanwhile Rogaway's patent on OCB expired and there is zero reason not to use OCB. FWIW, there has even always been a royalty free license for almost all software implementing OCB.

This may well be a good thing

Posted Dec 7, 2023 17:53 UTC (Thu) by ballombe (subscriber, #9523) [Link]

That should have been clarified in the article. This is a different usecase than normal PGP use.
Now proton is sitting on million of keys which are only protected by password that can be subject to various bruteforce attack. The security is much lower than what PGP provides.

This may well be a good thing

Posted Dec 7, 2023 18:09 UTC (Thu) by riking (subscriber, #95706) [Link] (1 responses)

Note: I believe that SRP is actually Secure Remote Password, because it proves possession of the shared authenticator using a challenge-response instead of encrypted direct transmission (e.g. TLS)

This may well be a good thing

Posted Dec 7, 2023 19:02 UTC (Thu) by dsommers (subscriber, #55274) [Link]

Hah! Yeah, that was a brainfart ... Secure Remote Password (RFC 2945) , that's what I meant. Thanks for spotting that!

https://en.m.wikipedia.org/wiki/Secure_Remote_Password_pr...

This may well be a good thing

Posted Dec 7, 2023 13:18 UTC (Thu) by pizza (subscriber, #46) [Link]

> Seems to me gpg is actually standing in the way of widespread email encryption by being utterly incomprehensible and unusable for non-experts.

When it comes to email, non-experts, just like experts, will interact with gpg via their email client, which provides all the functionality they will need. If the email's client UI is obtuse and unusable by non-experts, that's a problem with the client (or a fundamental property of [Open]PGP), not gpg itself.

(I can't remember the last time I used gpg on the command line for anything other than key creation, and even that was many, many years ago)

This may well be a good thing

Posted Dec 11, 2023 5:51 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

I think that's overstating it. It does seem the majority of people just aren't concerned with having their email encrypted, so you have to make it completely seamless, not just easy and comprehensible.

I'm willing to take a bet that, if all users had to do was hit a small button that said "Encrypt", less than 50% of non-mass emails would still be unencrypted.