Re: Should one really disable AEAD for recent GnuPG created PGP keys?
Hi Vincent! Thanks a lot for this insight! When it comes to encryption, I would consider myself a "power user", but still a user. I never heard of all this until now. What I, from the perspective of an end-user, saw was: I generate a new key. And then: "Pass no work on me phone anymore, OpenKeychain bad!" ;-) This whole thing is awkward. As a normal user, you currently have no chance to even know this. So, is what they propose in the Arch wiki the way to go to stick to non-embattled interoperable settings? (setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP)? I see the rationale for a performant block cipher. But that's nothing I need for my use-case; there's simply no advantage at all. Most probably for most users. So if there's no broad consensus about this, such an option should be hidden behind some "expert" flag, for people knowing what they do, and who are willing to trade off interoperability for performance. It should not be a default setting letting users like me run into problems they can't grasp without deep research. I don't want to join a "faction". I don't want to participate in a religious war. I just want to use encryption ... I'll file a Gentoo bug about this and see what the devs/maintainers say. Cheers, Tobias ___ 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?
Hey list, OpenKeychain maintainer here. As Werner chose to omit some details here that seem pertinent, I will add: No, it is not because you are delaying the deployment of new and a much faster algorithm mode. The packet format referred to here is GnuPG-specific. In November 2023, GnuPG forked the OpenPGP standard as "LibrePGP", in protest of the upcoming OpenPGP revision. See https://librepgp.org/ LibrePGP specifies the packet format that GnuPG now emits by default. However, this packet format will be different from the upcoming RFC specifying the next OpenPGP revision. You can find the LibrePGP mailing list here: https://lists.gnupg.org/pipermail/librepgp-discuss/ > Unfortunately a small group of people seem to sabotage this strategy > by rejecting the new mode despite that it has been implemented by > their crypto library. The "small group of people" that Werner is accusing of sabotage here is the IETF OpenPGP working group, and implementations that choose to implement the new OpenPGP RFC over LibrePGP. The background on this whole ordeal is complicated to say the least, but it is well established that the points of contention are rooted in personal conflict, and thus by nature extremely difficult to work with. All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js) took great care to first deploy the software with support for the new mode before actually creating keys with a preference for that mode [1]. Ultimately, as a user you can currently choose between a format that will not be part of the upcoming RFC, but is supported by GnuPG (and many other implementations, including those mentioned above). Or a format that will be standardized as an RFC, but is not supported by GnuPG (but many other implementations, including all mentioned above). Due to this situation, many distributors (at least: Thunderbird, Debian, Arch, Fedora, NixOS, GPG Suite for macOS) have decided to hold back emission of the LibrePGP packet format for now. OpenKeychain will also follow suit here. Cheers - V ___ 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?
Hey Bruce, On 04.03.24 21:53, Bruce Walzer wrote: * https://articles.59.ca/doku.php?id=pgpfan:noae_shame There is more if you search for it: https://kagi.com/search?q=gpg+%22packet+type+20%22=no_region=HeSUA3hoI5SeCuA2TTrNig Cheers - V ___ 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?
> Ah... That question leads to an awkward discussion these days. There > was a IETF standards process that led to the OCB mode now supported by > GnuPG and others. GnuPG (and others) implemented it before the new > standard was officially released (there seemed to be consensus). That > standards process then dropped the GnuPG OCB mode and created 3 new > modes. So currently, there are the two modes that the OpenPGP standard > currently specifies and four proposed modes for a total of 6 modes, > each completely incompatible with any other mode. So there is a > potential for a interoperability disaster here. > At this point I personally believe that everyone should step back from > this potential war and stop generating new modes by default. As a user > I can happily wait until an actual consensus is reached. Heck, I can > happily wait past that. There is no hurry here. Oh my. So the answer to my question "Should one really disable AEAD for recent GnuPG created PGP keys" (or OCB/AEAD or whatever) is maybe "yes" after all ... I mean, it's hard enough for most people to use public key encryption at all. Even if there are no interoperability issues. Maybe, one should agree on the lowest common denominator here. I encrypt passwords, sign software releases and sometimes (rarely), I encrypt an email. A text email. Which is like 4 KB or such. So, for me, I see no performance problem for my use-case. > The big usability problem now is that the implementations are not > making all this clear. GnuPG for instance doesn't even have an entry > in the FAQ about this problem. Most users will not be able to overcome > this sort of issue and will have to just give up. ... like most of them do anyway, when it comes to public key cryptography. > Anyway, I wrote a whole rant about this: > > * https://articles.59.ca/doku.php?id=pgpfan:schism > > I have added your Openkeychain references to my list of problems > caused by new OpenPGP cipher block modes. Thanks. > > * https://articles.59.ca/doku.php?id=pgpfan:noae_shame Thanks for this reference! Cheers, Tobias ___ 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 Mon, Mar 04, 2024 at 12:03:41PM +0100, Tobias Leupold via Gnupg-users wrote: [...] > After some research, I found > > https://github.com/open-keychain/open-keychain/issues/2886 , > > describing this exact issue. That would be the cipher block mode proliferation issue. > As a possible fix, disabling the unsupported AEAD > mechanism in the key itself was mentioned, the Arch folks write: > > https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism Thank you for this. Up to now I did not know how to do this for GnuPG. > > They also claim that "many downstreams attempt to remove this new default by > patching the GnuPG sources". I don't know if this is true, but I would not be surprised. It turns out that the current existing cipher block mode (OCFB-MDC, SEIP) is cryptographically secure, even though there are lot of misleading legends that insist that it is not. So as a user, I have no incentive to use another block mode unless I want higher encryption performance or different error handling. Few users actually want or need those features. All users want interoperability. That, after all, is why the OpenPGP standard exists. People with special needs normally use dedicated encryption utilities with no interoperability with anything else. > > I'm not that deep into cryptography. I'm not sure I completely grasp what > AEAD > and OCB mean. Just different terms for the same new and incompatible cipher block mode for the purposes of this discussion. > > So: Is it wise and/or necessary to disable that for new GnuPG generated keys, > for the sake of interoperability? Ah... That question leads to an awkward discussion these days. There was a IETF standards process that led to the OCB mode now supported by GnuPG and others. GnuPG (and others) implemented it before the new standard was officially released (there seemed to be consensus). That standards process then dropped the GnuPG OCB mode and created 3 new modes. So currently, there are the two modes that the OpenPGP standard currently specifies and four proposed modes for a total of 6 modes, each completely incompatible with any other mode. So there is a potential for a interoperability disaster here. > Or will the others catch up and implement it? Which mode(s) should they implement? There are at least two factions. It seems unlikely that any faction will implement the other faction's modes. > Or is there a good reason not to do so? At this point I personally believe that everyone should step back from this potential war and stop generating new modes by default. As a user I can happily wait until an actual consensus is reached. Heck, I can happily wait past that. There is no hurry here. The big usability problem now is that the implementations are not making all this clear. GnuPG for instance doesn't even have an entry in the FAQ about this problem. Most users will not be able to overcome this sort of issue and will have to just give up. Anyway, I wrote a whole rant about this: * https://articles.59.ca/doku.php?id=pgpfan:schism I have added your Openkeychain references to my list of problems caused by new OpenPGP cipher block modes. Thanks. * https://articles.59.ca/doku.php?id=pgpfan:noae_shame Bruce ___ 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?
Hi Werner, thanks for the clarification! > All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js) > took great care to first deploy the software with support for the new > mode before actually creating keys with a preference for that mode [1]. > Unfortunately a small group of people seem to sabotage this strategy by > rejecting the new mode despite that it has been implemented by their > crypto library. Well, or your version on Android is too old - which > would indicate a severe security problem anyway. This is not about (my) Android (version), I think this is more about OpenKeychain (still) not having implemented this. For whatever reason. However, I filed an issue for that: https://github.com/open-keychain/open-keychain/issues/2900 IMO interoperability with GnuPG is crucial for this project. Most people using that on their phones will come from Linux, or they will at least be GnuPG users. Let's hope for the best ... > RSA has nothing to do with this. You can safely switch to curve25519 > (ed25519/cv25519) for new keys - they are supported even longer than OCB > mode (aka AEAD). Good to know! ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [gpg-agent] Empty OPTION xauthority=
On Mon Mar 4, 2024 at 9:13 AM CET, Werner Koch wrote: > Because all components of gnupg will start gpg-agent and the other > daemons oin the fly and make sure that only one is started. Do I understand it correctly that gnupg contains smaller version of systemd (dependency activation) inside of itself and that clashes with systemd? Is there some way how to switch it off and to make individual parts of gnupg behaving just The Unix Way™, do one thing (cryptographic operations, gpg-agenting or whatever) and do it well? > I have no idea what this is about. In case you need to play interesting > games with the sockets, the gpgconf.ctl mechanism might be helpful. MicroOS by openSUSE (and Fedora Atomic and many others, every Linux distro has its own variant of this, I guess) are container-oriented systems, where only minimal host system is used to run multiple isolated containers (Docker/Podman, distrobox, or Flatpak). SELinux and other methods are used to keep these containers isolated from the host system and one from another, sockets are under proper circumstances accessible. > Using no-autostart in the common.conf might be useful. We use it always > when running a remote gpg. That looks interesting, I will look into that. Best, Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Ludwig Boltzmann, who spent much of his life studying statistical mechanics, died in 1906, by his own hand. Paul Ehrenfest, carrying on the work, died similarly in 1933. Now it is our turn to study statistical mechanics. -- David L. Goodstein “States of Matter” E09FEF25D96484AC.asc Description: application/pgp-keys signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Your message to Gnupg-users awaits moderator approval
On Mon Mar 4, 2024 at 2:19 PM CET, gnupg-users-owner wrote: > Your mail to 'Gnupg-users' with the subject > > Re: [gpg-agent] Empty OPTION xauthority= > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message body is too big: 63276 bytes with a limit of 40 KB > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > https://lists.gnupg.org/mailman/confirm/gnupg-users/c419b7597f95abe2ff1d83ed3340aeb711643a59 Hi, I have enabled in my email client the feature attaching signing key and I thought that the attachment is just few (in single units) kB long, but suddenly I am getting the warning messages like this one. My key has been signed by 60+ signatures, but still 45K just for that seems excessive. Is there some way how to generate something meaningful, which would be smaller? Best, Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A philosopher like Plato, according to Luther’s colorful imagery, remains like a cow who looks at a new door, refusing to enter? E09FEF25D96484AC.asc Description: application/pgp-keys signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [gpg-agent] Empty OPTION xauthority=
On Mon, 4 Mar 2024 14:19, Matěj Cepl said: > Do I understand it correctly that gnupg contains smaller version > of systemd (dependency activation) inside of itself and that No. It is not required. Just don't let systemd start gpg-agent or dirmngr with option --supervised. If you use ssh just make sure that gpg-agent has been started - this is the same as with ssh-agent. > MicroOS by openSUSE (and Fedora Atomic and many others, > every Linux distro has its own variant of this, I guess) are > container-oriented systems, where only minimal host system > is used to run multiple isolated containers (Docker/Podman, > distrobox, or Flatpak). SELinux and other methods are used to I see. We once looked into running a gpg-agent under a different account and with the right glue it should work. Definitely needs some more work but given that remote use works, it should not be a major hassle. The gpgconf.ctl hack might come handy to force the use of a different socket directory - see the latest gpgconf man page. Depends on how things are actually done. There is even a --chuid option to gpgconf to handle things for a user during session startup. Shalom-Salam, 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
Re: Should one really disable AEAD for recent GnuPG created PGP keys?
On Mon, 4 Mar 2024 12:03, Tobias Leupold said: > So: Is it wise and/or necessary to disable that for new GnuPG generated keys, > for the sake of interoperability? Or will the others catch up and implement No, it is not because you are delaying the deployment of new and a much faster algorithm mode. Although OpenPGP provides a nice preference system to convey the capabilities of your software it has the obvious problem that you need to change the preferences when moving to another software. In fact gpg has always asked you to update the preferences if it detected a different set. Using the same key with different software is and will always be problematic. I would also consider the security drawbacks of doing so. The attack surface of an Android phone is far higher than of your well maintained Unix or Windows desktop. Thus it may be useful to reflect this by using different keys or at least subkeys. All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js) took great care to first deploy the software with support for the new mode before actually creating keys with a preference for that mode [1]. Unfortunately a small group of people seem to sabotage this strategy by rejecting the new mode despite that it has been implemented by their crypto library. Well, or your version on Android is too old - which would indicate a severe security problem anyway. > it? Or is there a good reason not to do so? Should one keep using legacy RSA > keys? Is it too early to switch to more modern ones? RSA has nothing to do with this. You can safely switch to curve25519 (ed25519/cv25519) for new keys - they are supported even longer than OCB mode (aka AEAD). Salam-Shalom, Werner [1] OCB (AEAD) decryption implemented by GnuPG with versions: 2.3.0-beta (January 2018) - interop tested with RNP and OpenPGP.js 2.3.0 (April 2021) 2.2.21 (July 2021) -- 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
Re: No secret key
Hi, First of all: The usual procedure when asking for advice is to tell us which gpg version you are using. And on which operation system. But it seems likely that in this case the info is not necessary. > I received this message when using --clear-sign. > gpg: no default secret key: No secret key > gpg: clear-sign dialed: No secret key Please always post complete gpg comand lines and the corresponding output - you can of course obfuscate names and other personal info. I assume you have entered something like: gpg --clear-sign test.txt without specifiying the key to use on the command line and no default key defined in you gpg.conf. The gpg man page describes how to specify that key: --clearsign Make a cleartext signature. The content in a cleartext sig‐ nature is readable without any special software. OpenPGP software is only needed to verify the signature. cleartext signatures may modify end-of-line whitespace for platform in‐ dependence and are not intended to be reversible. The sign‐ ing key is chosen by default or can be set explicitly using the --local-user and --default-key options Therefore, If you did not set a default key in your gpg.conf, you have to provide the key to use on the command line as described. Regards Eva ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Should one really disable AEAD for recent GnuPG created PGP keys?
Hi all :-) Apparently, there are some problems with the new defaults that are set when one creates a PGP key using a recent version of GnuPG (2.4). I ran into this after generating a new ECC/ED25519 key to replace my "old" RSA one. The problem showed up when I re-encrypted my pass password store passwords with the new key: After transferring the key to my Android phone and importing it into OpenKeychain, I could not decrypt any passwords anymore. After some research, I found https://github.com/open-keychain/open-keychain/issues/2886 , describing this exact issue. As a possible fix, disabling the unsupported AEAD mechanism in the key itself was mentioned, the Arch folks write: https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism They also claim that "many downstreams attempt to remove this new default by patching the GnuPG sources". I'm not that deep into cryptography. I'm not sure I completely grasp what AEAD and OCB mean. So: Is it wise and/or necessary to disable that for new GnuPG generated keys, for the sake of interoperability? Or will the others catch up and implement it? Or is there a good reason not to do so? Should one keep using legacy RSA keys? Is it too early to switch to more modern ones? Thanks to all cryptography experts for all clarification! Cheers, Tobias ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
No secret key
Sirs and ladie! I received this message when using --clear-sign. gpg: no default secret key: No secret key gpg: clear-sign dialed: No secret key Both my public and private key has been imported. The key was made with a different user (as sudo)The current user is a non-sudo user. Yours truly Richardh Bostrom 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: [gpg-agent] Empty OPTION xauthority=
On Sun, 3 Mar 2024 20:38, Matěj Cepl said: > 1. Could you please explain why it is racy? Why from all services Because all components of gnupg will start gpg-agent and the other daemons oin the fly and make sure that only one is started. Systemd does not know about this specific start mechanism and thus you might see two daemon processes for some time until their self-check detects this situation. In most cases this is just a annoying but it may very well happen that the two processes receove different information and are not abale to properly handle the caching. With smartcards you may also run into lockups becuase only one process may hold access to a smartcard. With keyboxd we even didn't implement the systemd start thingy because keyboxd acquires a process lifetime lock on the database and thus a second process won't be abale to get that lock and timeout after some time. > 2. When running on MicroOS system (or Fedora Atomic) how could >you guarantee that there is only one gpg-agent and gpg >doesn't try to run it inside of a container, thus making it I have no idea what this is about. In case you need to play interesting games with the sockets, the gpgconf.ctl mechanism might be helpful. Using no-autostart in the common.conf might be useful. We use it always when running a remote gpg. > What? You know there is a vulnerability in gpg (actually, > couldn't the particularly modified environment be abused for some Please read again what I wrote: An empty string for the value is simply invalid syntax. That is different from not giving a value which is specified as removing the envvar (cf. "" vs. NULL). > I have Wayland-only system (based on sway), so whole XAUTH* > variables are nonsensical here. Others might be: $ gpg-connect-agent 'getinfo std_env_names' /bye D GPG_TTY D TERM D DISPLAY D XAUTHORITY D XMODIFIERS D WAYLAND_DISPLAY D XDG_SESSION_TYPE D QT_QPA_PLATFORM D GTK_IM_MODULE D DBUS_SESSION_BUS_ADDRESS D QT_IM_MODULE D INSIDE_EMACS D PINENTRY_USER_DATA D PINENTRY_GEOM_HINT 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
