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
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?
Sorry for asking another thing about this. For sure, I didn't want to set off an avalanche, and I still don't want to. But from a user's perspective, this is simply very confusing and also unsettling. I think that somewhere, there should be some documentation, FAQ or whatever, as a definitive source for the correct facts. Because we have this statement: > That is not a GnuPG specific but an agreed upon format by the participants > of the OpenPGP WG and implemented by all major implementations. Which does not match what others say (apart from Vincent's statement) ... e.g. I also asked for what to do on Stack Exchange: https://security.stackexchange.com/questions/275883/should-one-really-disable-aead-for-recent-gnupg-created-pgp-keys The answer started with: > While authenticated encryption (AEAD) is good - especially for something > like OpenPGP, which is an old and over-complicated standard that has a > concerning large attack surface for vulnerabilities or simple implementation > errors - I definitely can't recommend enabling a non-standardized > compatibility-breaking feature by default, and frankly feel that GnuPG made > a major error in doing so from somebody with an impressive reputation on the network, for whom I suppose he knows what he's talking about. So: Is this standardized, or is it not? As said: I don't want to provoke a flame war. I'm just interested in objective facts ... ___ 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: 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
