Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add support for OCB (AEAD) encryption #2900

Open
l3u opened this issue Mar 4, 2024 · 4 comments
Open

Please add support for OCB (AEAD) encryption #2900

l3u opened this issue Mar 4, 2024 · 4 comments

Comments

@l3u
Copy link

l3u commented Mar 4, 2024

Dear devs,

first of all thanks a lot for bringing PGP encryption to Android via OpenKeychain! Kudos for this outstanding work! However, recently, a problem surfaced:

Recent versions of GnuPG (> 2.3) are meanwhile stabilized on the major Linux distributions (Gentoo Linux in my case). The default setting for newly created PGP keys is to use OCB (AEAD) encryption, which is not supported by OpenKeychain at the moment. This leads to interoperability problems, which have been reported by different means and describing different symptoms, but after all, it's always about OpenKeychain not supporting OCB (AEAD) encryption. Cf. e.g. android-password-store/Android-Password-Store#1429, #2096 or #2886. Some date back to 2017.

According to the GnuPG mailing list, OCB (AEAD) support has been added to GnuPG back in version 2.3.0-beta in January 2018.

Some advise to disable this encryption scheme in the key to obtain interoperability, like stated in the Arch Wiki. But this is for sure not the way to go to address the problem. One can expect that more and more keys will be generated using GnuPG and the default settings – and this problem will emerge over and over again.

So, just to file an issue that names the root cause for this problem: Please support OCB (AEAD) so that OpenKeychain will interoperate with GnuPG!

Thanks a lot in advance for working on this!

@l3u
Copy link
Author

l3u commented Mar 5, 2024

Oh my. This is complicated. Apparently, we have a religious war here … also cf. https://security.stackexchange.com/questions/275883/should-one-really-disable-aead-for-recent-gnupg-created-pgp-keys

@viktor-yakubiv
Copy link

@l3u thank you so much for bringing this! Linked documents have helped me to tackle the issue I faced.

Literally, I spend the whole day yesterday digging into why Password Store cannot decrypt my passwords from the computer, while vice versa it worked just fine. It was just saying "Open Keychain exception".

Comparing packets with gpg --list-packets for the same text encrypted on phone and computer, I have found that Open Keychain uses AES-CBC 128. I could not find the way to configure the same in my GnuPG 2.4, only 192, 256. On the other side, I've seen misterious AEAD. Neither meant anything to me. (I am not sure if cipher length worth addressing.)

While I understand the situation described on Stack Exchnage, I agree with the first comment in this issue: supporting OCB (AEAD) would redure the problem from being reported over and over again.

On the other side, I understand this might not be straightforward. However, if possible to identify programmatically AEAD packet and give a nicer error message, maybe pointing to a piece of documentation, it would help many people identify what the problem is and how to address it. I have tried many things before arriving here.

@l3u
Copy link
Author

l3u commented Mar 6, 2024

Additional information concerning this: android-password-store/Android-Password-Store#2936 – PGPainless also won't add support for GnuPG's AEAD (OCB) block cipher. As OpenKeychain won't, according to the project maintainer.

Well, maybe GnuPG is to blame here and not everybody else …

@yescallop
Copy link

Last year I made a patch that adds AEAD support to OpenKeychain. It's been working perfectly for nearly a year, during which I used the patched version of OpenKeychain and GPG 2.4+ to encrypt and decrypt a bunch of files created by each other with an AEAD-enabled key. It would be nice if someone can turn this patch into one that is acceptable upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants