Live data from Hacker News

A New Future for GnuPG

gnupg.org

31–36 of 36 posts

Re: A New Future for GnuPG

#31
post #11

GnuPG needs to push to update OpenPGP to stay alive. OpenPGP needs to be updated. It lacks modern AEAD (the practical impact of a better authentication might be low in many use cases; but it has become a political problem). The code base and CLI could also be modernized so that developers could easily use its API. Sequoia is doing a good job here. Otherwise, it risks becoming obsolete.

> It lacks modern AEAD (the practical impact of a better authentication might be low in many use cases; but it has become a political problem).

For AEAD and OpenPGP, there seem to be limitations in the message format:

* https://datatracker.ietf.org/doc/html/draft-ford-openpgp-for...

Newer versions of GPG do support AEAD modes of operation, but AFAICT they only appear in the "encrypted data" part of the resulting bucket of data and not in the "signature" part. The algorithms are generally supported though; search for 'aead':

* https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Op...

* https://www.gnupg.org/documentation/manuals/gcrypt/Available...

Re: A New Future for GnuPG

#32
post #30
post #27

On the one hand, I am glad it finally got the proper funding. On the other hand, I would prefer more effort going into more modern implementations [1] or protocols[2][3]. [1] https://sequoia-pgp.org/ [2] https://www.cryptologie.net/article/502/alternatives-to-pgp/ [3] https://blog.gtank.cc/modern-alternatives-to-pgp/

And here we go, typical HN post flogging the virtues of GPG/PGP alternatives as some sort of "modern" implementation that by virtue of "modern" somehow makes it better than GPG. In my day we used GPG and we liked it. Need to use a smartcard with a GPG key to SSH? well tie an onion to your belt and get ready to pull a standing triple gainer in bash. did you get the password prompt? well now its time to dive further yo…

Not sure if someone out there is compiling a list of Hacker News copypasta, but if you are please do not forget to add this.

Re: A New Future for GnuPG

#33
post #11

GnuPG needs to push to update OpenPGP to stay alive. OpenPGP needs to be updated. It lacks modern AEAD (the practical impact of a better authentication might be low in many use cases; but it has become a political problem). The code base and CLI could also be modernized so that developers could easily use its API. Sequoia is doing a good job here. Otherwise, it risks becoming obsolete.

> It lacks modern AEAD (the practical impact of a better authentication might be low in many use cases; but it has become a political problem). For AEAD and OpenPGP, there seem to be limitations in the message format: * https://datatracker.ietf.org/doc/html/draft-ford-openpgp-for... Newer versions of GPG do support AEAD modes of operation, but AFAICT they only appear in the "encrypted data" part of the resulting buck…

The world is going to be locked into legacy CFB+MDC PGP pretty much indefinitely (because of the need to be compatible with an installed base which, owing to asynchronous messaging, can't be queried or negotiated with). As a result, to defend PGP as an ongoing practice, you're rhetorically required to argue that authenticated encryption --- not just modern AEAD, but the whole concept of authenticating ciphertext --- is overrated; 20 years of cryptographic research be damned.

Re: A New Future for GnuPG

#34
post #33

Earlier quoted context omitted.

> It lacks modern AEAD (the practical impact of a better authentication might be low in many use cases; but it has become a political problem). For AEAD and OpenPGP, there seem to be limitations in the message format: * https://datatracker.ietf.org/doc/html/draft-ford-openpgp-for... Newer versions of GPG do support AEAD modes of operation, but AFAICT they only appear in the "encrypted data" part of the resulting buck…

The world is going to be locked into legacy CFB+MDC PGP pretty much indefinitely (because of the need to be compatible with an installed base which, owing to asynchronous messaging, can't be queried or negotiated with). As a result, to defend PGP as an ongoing practice, you're rhetorically required to argue that authenticated encryption --- not just modern AEAD, but the whole concept of authenticating ciphertext ---…

As per the links I posted, drafts have been written acknowledging AEAD as something worth having, and code has been added to support those cipher modes. I don't think that anyone is is ignoring authenticating cipher text. But as you said, there's an installed base of, e.g., RHEL7, that cannot handle that. Some code does not churn as fast as semi-monthly web browser releases.

If you do not like PGP/GPG, you 'just' have to create a better way of doing things, and then 'just' have to convince everyone to switch their workflows to it.

Re: A New Future for GnuPG

#35
post #11

GnuPG needs to push to update OpenPGP to stay alive. OpenPGP needs to be updated. It lacks modern AEAD (the practical impact of a better authentication might be low in many use cases; but it has become a political problem). The code base and CLI could also be modernized so that developers could easily use its API. Sequoia is doing a good job here. Otherwise, it risks becoming obsolete.

>...the practical impact of a better authentication might be low in many use cases; but it has become a political problem... In the ways that GnuPG is normally used the practical impact is zero because that is not how a stateless, offline protocol works. The content is authenticated by signing it directly, thus avoiding the extra complexity of a stateful connection oriented authentication scheme. The details here: *…

This is a category error. Authenticated encryption does not require statefulness. Just look at NaCl's cryptobox.

Re: A New Future for GnuPG

#36
post #35

Earlier quoted context omitted.

>...the practical impact of a better authentication might be low in many use cases; but it has become a political problem... In the ways that GnuPG is normally used the practical impact is zero because that is not how a stateless, offline protocol works. The content is authenticated by signing it directly, thus avoiding the extra complexity of a stateful connection oriented authentication scheme. The details here: *…

This is a category error. Authenticated encryption does not require statefulness. Just look at NaCl's cryptobox.

The state is the authentication here. For stuff that is only sent once you can check the signature and you are done. Otherwise you have to maintain it for the duration of the connection and you are not going to want to sign every single message sent.
Post reply on HN