Re: Should one really disable AEAD for recent GnuPG created PGP keys?
On Wed, Mar 06, 2024 at 09:43:00AM +0100, Werner Koch wrote: > On Tue, 5 Mar 2024 11:15, Bruce Walzer said: > > > So just to be clear, I am not complaining that GnuPG implemented the > > LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3 > > before implementation was close to universal and did not clearly spell > [...] > OCB mode is only used if all recipient's key have the flag that they > support this mode. Yes, and I agree that the preference system here is helpful. But I have a list of 22 instances where it did not work. Those are up to this point entirely from GnuPGP emitting new block cipher modes and are mostly between different versions of GnuPG. Things could easily get worse going forward. > This is not different from the preferences for a certain cipher > algorithm. For example AES in the old days. The migration from > CAST5 to AES worked without any noticeable problems because after we > implemented AES, we announced that in the keys and the peers started > to use AES iff all recipients claimed that they support this flags. The difference here is that most users have a general idea of what these algorithms are and what it means when support for decytption is not available. Few people know about cipher block modes. The messages that they get won't even refer to cipher block modes, instead it will be some sort of obscure internal error. For example, GnuPG says this: gpg: [don't know]: partial length for invalid packet type 20 > Same thing for for compression algorithms. At some point we were > talked round to implement bzip2. How many implementations specify bzip2 as the most desired compression mode by default? Back in the day, most OpenPGP users were on the same mailing lists. That is no longer true. This is a good thing. The OpenPGP standard and GnuPGP in particular are widely and routinely used. [...] > Now, when you move to another software with less capabilities, you > need to announce that to your peers by sending an updated key with > the new set of preferences. Sure there is a problem with low end > mobile device software which you use with the same key - in this > case you need to drop the preferences which are not supported by > your mobile device software. Mailvelope for example, provides no way to modify preferences. Most implementations do not. So, practically, this will be done with the GnuPGP editor. That editor is not very accessible for most users. The user would have to export then import to GnuPGP. Then somehow determine the capabilities of all their implementations (and all the versions of those implementations they are using). Then they would find a common subset and edit it into the new key. Then they would export the key back to all the implementations, keyservers and non-server using correspondents. Certainly possible but it is a lot to ask. These are the sorts of things that allow others to claim that the OpenPGP ecosystem is complex and unusable. Anyway, this is not about my greatest fear. That fear is that the cryto refresh will someday be released as the official RFC-4880. If any significant implementation follows this exclusively, then there will be an actual "schism". If everyone emits new modes by default then the two islands of compatibility will not be able to interoperate. To the extent that the preferences were helpful, it would be by using the existing block cipher mode to bridge the gap. I would be OK with this but I doubt that most would. It would make the introduction of the new modes seem pointless. What happens then? Making this personal, I sometimes write PGP advocacy articles. How should I attempt to sell this new change? Faster encryption and different error handling, great. But that doesn't seem enough to justify obscure, possibly time delayed, interoperability problems even if they are rare. Bruce ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Clearsign
Dear Fellows! Importing my private key is flawless but signing is faulty. May I ask for your help? Sent with [Proton Mail](https://proton.me/) secure email.___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to download commit packages from gnupg phabricator?
Hi! On Wed, 6 Mar 2024 20:20, Vladimir Nikishkin said: > However, I don't seem to be able to find a way to download a tarball > of the commit in any way. You man a tarball made from the repository at that commit? In general we only publish traballs. If you want to use a working thing (i.e. git) then you need to build from git. We like well versioned releases. > But for some reason the links like > https://dev.gnupg.org/source/gpgpass/zip/master/;f46437b49b30257a7e98f98803c42c369b0748e8.zip That is quite possible; we never configured it. dev.gnupg.org is in most cases only a "mirror"[1] of our main repo server. Salam-Shalom, Werner [1] For a distributed VCS like Git the term "mirror" is of course a bit questionable. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
How to download commit packages from gnupg phabricator?
Dear All, I would like to try the GnuPG Password Manager (https://dev.gnupg.org/source/gpgpass/) However, I don't seem to be able to find a way to download a tarball of the commit in any way. I looked at the source of Phabricator, and it seems that support for downloading zips exists: https://secure.phabricator.com/rP8bb6e807f097b2eb58f863822d64c5078878355d But for some reason the links like https://dev.gnupg.org/source/gpgpass/zip/master/;f46437b49b30257a7e98f98803c42c369b0748e8.zip or https://dev.gnupg.org/source/gpgpass/zip/;f46437b49b30257a7e98f98803c42c369b0748e8.zip don't seem to work -- Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Should one really disable AEAD for recent GnuPG created PGP keys?
On Tue, 5 Mar 2024 11:15, Bruce Walzer said: > So just to be clear, I am not complaining that GnuPG implemented the > LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3 > before implementation was close to universal and did not clearly spell Sorry, this is not true. OCB mode is only used if all recipient's key have the flag that they support this mode. This is not different from the preferences for a certain cipher algorithm. For example AES in the old days. The migration from CAST5 to AES worked without any noticeable problems because after we implemented AES, we announced that in the keys and the peers started to use AES iff all recipients claimed that they support this flags. Same thing for for compression algorithms. At some point we were talked round to implement bzip2. The WG agreed on a code point for this and GnuPG implemented it. It is really rare that you get messages which you can't decrypt due to the non-supported compression algo. The preference system does it works. Now, when you move to another software with less capabilities, you need to announce that to your peers by sending an updated key with the new set of preferences. Sure there is a problem with low end mobile device software which you use with the same key - in this case you need to drop the preferences which are not supported by your mobile device software. > block cipher mode and do whatever else will speed things up. The user, > of course, would be made aware the the resulting files might not be > decryptable everywhere. If your key claims that it supports this feature it is decryptable - or you forgot to distribute the fact that you moved to a less capable software. Right, for symmetric only encryption the preferences don't work. But in this case you need to negotiate parameters and passwords anyway. > Arch Linux is just dropping #3 with their patch. Their version of > GnuPGP still supports the OCB mode and can generate it. So they are Sure they can do that. However, I don't think that this is a good decision. With the same argument we would still be using CAST5 or Twofish or even Blowfish. > distributions were not tempted to issue such patches. There really > should be a better way of doing this. Otherwise the users will > encounter different behaviour on different Linux distributions. Agreed. Let the preferences work for you. And also nag Vincent et al to stop crippling their software (rejecting OCB). After all BouncyCastle supports ed25519 which is also not specified by an RFC or anything else except the way gpg implemented the details of that curve. Such public key algorithms can't even be managed by the preference system. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
