4

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.

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?

Improve this question

1 Answer 1

Reset to default
3

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. If any of your systems are not using GnuPG specifically, or even are just using an older version of it, they can't be expected to implement a non-standard feature.

From a security perspective, I'm not even sure that just adding an OCB-based AEAD mode actually helps anything, in expectation; OpenPGP messages can already be authenticated in a few different ways, so arguably the likeliest source of security flaws is that the message format is too complex, not that it needs new features. If this mode replaced some of the other message authentication features that have been added over the years, that would be an improvement, but even then it really needs to be added to the standard before even considering turning it on by default.

Given that you work with non-GnuPG clients, and that this feature is not part of the OpenPGP specification, and that OpenPGP already includes message authentication and integrity, I recommend disabling this feature for now.

It's worth noting that you can disable it for an existing key, and later re-enable it, without needing to generate new keys. Also, this has nothing to do with RSA vs. ECC/Ed25519 keys; the key blob includes information about what features you (as a recipient, or rather your client) support, but the asymmetric key type used for signing and symmetric key exchange has nothing at all to do with the symmetric bulk encryption algorithm or mode of operation. If you generated a new RSA key right now it would also have this feature enabled, you could enable it on your old key if you wanted to, and you can (and IMO should) safely disable it on your existing key to restore compatibility with non-GPG clients. Note that you'll have to re-encrypt the data for non-GPG clients after disabling this non-standard feature.

Improve this answer
6
  • Thanks a lot for this insight. From an "end-user's" perspective, this is really awkward, as the whole thing actually seems to be some kind of "religious war" … as if that whole encryption stuff wasn't hard enough itself ;-) I'm pretty sure this will help a lot of people.
    – Tobias Leupold
    Commented Mar 5 at 9:30
  • Additional info: github.com/android-password-store/Android-Password-Store/… – neither PGPainless nor OpenKeychain (info from an email written by the project's maintainer to me) will add support for GnuPG's AEAD (OCB) block cipher.
    – Tobias Leupold
    Commented Mar 6 at 13:17
  • AEAD is absolutely a part of the new OpenPGP specification, which is awaiting publication and will be a full RFC shortly. I was part of the working group when it was added and I wrote part of the spec. It is also absolutely a major improvement over the old approach.
    – bk2204
    Commented Mar 6 at 23:34
  • @bk2204 The RFC has been in progress for quite a while without being made official, so who knows when it comes. Besides that, publishing an RFC doesn't mean it becomes implemented in all applications the other day. So when compatibility is a concern, there's unfortunately no way around being reluctant for another while.
    – not2savvy
    Commented Mar 7 at 15:17
  • 2
    I certainly hope that once it is standardized, other implementations adopt this feature soon (assuming the standard isn't deeply flawed in some way, of course). That's especially true if it's as much of an improvement as claimed. Still, at the end of the day, it's poor behavior for GnuPG to default enable a not-yet-standardized and compatibility-breaking change, and completely reasonable to disable it for now if you use non-gpg clients.
    – CBHacking
    Commented Mar 11 at 8:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .