Interoperability Issue Between gpg4win - Kleopatra and OpenKeyChain
Closed, WontfixPublic
Actions

Assigned To

Authored By

	GPGNewbie9000
	Aug 12 2022, 12:02 AM

Description

This is a re-opening of a query that was summarily closed without providing me the opportunity to respond.
Below please find the original post and the response by the individual who closed the issue.

I will address the items raised in the responder's post here:

Dear ikloecker, there is not even one offensive word in my query. I do not understand why you think that I was "yell at us." I can only guess that you took offense at my sentence that used ALL CAPS. I did that solely for the purpose of drawing the readers eyes to that sentence because my query was long and sometimes the major part of a request gets overlooked when it is in amongst a bunch of other text. If that is your concern, then I apologise that you took offense to capital letters.

My query did in fact list the version of gpg4win as 4.0.3 If there is some other designation that you require, please advise me of such and I will happily provide.

I am not a programmer anymore. I was decades ago. I am not a pgp / gpg expert either. I used whatever the default settings were in gpg4win / Kleopatra and the default settings in OpenKeyChain. If you can explain how I can reveal what the defaults are in each program, I will happily provide those details as well. In addition to that I can re-install gpg4win and create test keys and create a test file and include all of them in a reply. No hesitation there either.

If the default for gpg4win is to use the AEAD feature that you and the Github article refer to, then yes I understand why a key created originally from gpg4win / Kleopatra would be rejected by OpenKeyChain. However, when I created keys on OpenKeyChain and then imported them to gpg4win / Kleopatra and then tried to use those imported keys to encrypt a file on gpg4win / Kleopatra and email it to my smartphone and tried to decrypt using OpenKeyChain, it failed. This I do not understand since the keys were originally created on OpenKeyChain. Does the importing of those keys to gpg4win / Kleopatra enable the AEAD feature by default somehow on an imported keys ?

Can you please advise how to disable this AEAD feature in gpg4win / Kleopatra since the problem is not solved for me since I cannot use keys that are created with either the Windows program nor the Android program to email from Windows gpg4win / Kleopatra to Android OpenKeyChain. I indicated this in my query. Sorry if that was unclear to you.

If you confidently state it is not a bug and is simply that AEAD must be disabled in gpg4win / Kleopatra to resolve my issue, and if that is true even though the imported keys that were created by OpenKeyChain and then imported to gpg4win / Kleopatra still would not allow successful transmission from gpg4win / Kleopatra to OpenKeyChain, please advise me how to disable AEAD and I will happily re-test and report back my findings.

Thank you for your anticipated assistance.
GPGNewbie9000

Original Post and Response:

If you encrypt a file with Windows gpg4win / Kleopatra and email it to an Android device and try to use OpenKeyChain to Decrypt you receive the following error:

Unknown filename (touch to open)

Encountered an error reading input data!

Processing input data
Attempting to process OpenPGP data
Encountered an error reading input data!

This problem occurs both if you create the keys on gpg4win / Kleopatra and export to OpenKeychain AND if you create the keys on OpenKeyChain and export to gpg4win.

If you create keys on OpenKeyChain and export the keys to gpg4win / Kleopatra, you are able to encrypt a file on Android OpenKeychain and email to Windows device and use gpg4win / Kleopatra to decrypt.

If you create keys on gpg4win / Kleopatra and export to OpenKeyChain and then try to encrypt on Android OpenKeyChain and email to Windows device gpg4win / Kleopatra, the file will not decrypt.

There is something in the creation of keys on gpg4win / Kleopatra that is not working properly with OpenKeyChain.
This has been reported on Github, but it was thought to be a problem with OpenKeyChain. However, based on the behavior, I believe it is a problem which is in gpg4win / Kleopatra.

Here are the Github links:

https://github.com/open-keychain/open-keychain/issues/2096

https://github.com/keybase/keybase-issues/issues/4025#issuecomment-874497887

PLEASE DEBUG AND PATCH GPG4WIN / KLEOPATRA AS SOON AS POSSIBLE. INTEROPERABILITY OF PGP / GPG BETWEEN WINDOWS AND ANDROID IS IMPERATIVE.

Thank you.

Version

gpg4win 4.0.3

ikloecker closed this task as Invalid.Thu, Aug 11, 10:29 PM
ikloecker added a subscriber: ikloecker.
Comment Actions

Please don't yell at us!

If you want us to take your bug report seriously, then you really have to give us more details. Start by telling us which version of gpg4win you are using. Next tell us what kind of keys are you using? Maybe you can create test keys and add them to this bug report. And you can attach an encrypted test file to this bug report, so that we can check whether we see anything peculiar.

But wait ...

Reading https://github.com/open-keychain/open-keychain/issues/2096 it seems that OpenKeyChain doesn't support AEAD. gpg 2.3 (and a gpg4win using this version) will use AEAD encryption if the keys indicate that an AEAD algorithm can be used. Obviously, keys created with gpg 2.3 will indicate this.

If you need interoperability with other implementations of OpenPGP that lacks features like AEAD, then you have to make sure that the keys you use do not indicate features that the other implementation of OpenPGP, e.g. OpenKeyChain, doesn't support. Incidentally, you have already found the solution: Simply create the keys with OpenKeyChain and be happy.

I'm closing this issue because there is no bug in gpg. And there is no bug in OpenKeyChain either. There is simply a feature missing in OpenKeyChain which forces you to take care to use only keys that are compatible with OpenKeyChain.

Details

Version: gpg4win 4.0.3

Related Objects

Mentioned Here: rG1908fa8b835c: gpg: Improve --edit-key setpref.

Event Timeline

GPGNewbie9000 created this task.Aug 12 2022, 12:02 AM

GPGNewbie9000 updated the task description. (Show Details)Aug 12 2022, 12:12 AM

Here are two test keys I created with gpg4win 4.0.3 after reinstalling.

TestKey1_0x31B038AA_public.asc665 BDownload

TestKey1_0x31B038AA_SECRET.asc767 BDownload

TestKey2_0x22ACA897_public.asc665 BDownload

TestKey2_0x22ACA897_SECRET.asc767 BDownload

Here are two keys that I created on OpenKeyChain. They are in an encrypted backup file:

backup_2022-08-11.sec.pgp13 KBDownload

Here is the passphrase in a text document:

Passphrase_For_Backup_of_OpenKeyChain_test_keys.txt89 BDownload

I hope that these 4 test keys can enable someone to guide me how to make the two programs,
gpg4win / Kleopatra and OpenKeyChain create keys that will allow decryption to work properly when emailing between Windows and Android.

Thank you for your help.

Some details about TestKey1_0x31B038AA:

$ gpg --show-keys --verbose TestKey1_0x31B038AA_public.asc 
pub   ed25519/CD1E530031B038AA 2022-08-12 [SC] [expires: 2024-08-11]
      A438C95B6CAA724BC9F3DEB9CD1E530031B038AA
uid                            TestKey1 <TestKey1@Email>
sub   cv25519/B390B84B58866C6A 2022-08-12 [E] [expires: 2024-08-11]

$ gpg --list-packets TestKey1_0x31B038AA_public.asc 
# off=0 ctb=98 tag=6 hlen=2 plen=51
:public key packet:
        version 4, algo 22, created 1660270147, expires 0
        pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1)
        pkey[1]: [263 bits]
        keyid: CD1E530031B038AA
# off=53 ctb=b4 tag=13 hlen=2 plen=25
:user ID packet: "TestKey1 <TestKey1@Email>"
# off=80 ctb=88 tag=2 hlen=2 plen=153
:signature packet: algo 22, keyid CD1E530031B038AA
        version 4, created 1660270147, md5len 0, sigclass 0x13
        digest algo 10, begin of digest 0d 5f
        hashed subpkt 33 len 21 (issuer fpr v4 A438C95B6CAA724BC9F3DEB9CD1E530031B038AA)
        hashed subpkt 2 len 4 (sig created 2022-08-12)
        hashed subpkt 27 len 1 (key flags: 03)
        hashed subpkt 9 len 4 (key expires after 2y0d13h50m)
        hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
        hashed subpkt 34 len 1 (pref-aead-algos: 2)
        hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        hashed subpkt 30 len 1 (features: 07)
        hashed subpkt 23 len 1 (keyserver preferences: 80)
        subpkt 16 len 8 (issuer key ID CD1E530031B038AA)
        data: [252 bits]
        data: [253 bits]
# off=235 ctb=b8 tag=14 hlen=2 plen=56
:public sub key packet:
        version 4, algo 18, created 1660270147, expires 0
        pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1)
        pkey[1]: [263 bits]
        pkey[2]: [32 bits]
        keyid: B390B84B58866C6A
# off=293 ctb=88 tag=2 hlen=2 plen=126
:signature packet: algo 22, keyid CD1E530031B038AA
        version 4, created 1660270147, md5len 0, sigclass 0x18
        digest algo 10, begin of digest 29 fc
        hashed subpkt 33 len 21 (issuer fpr v4 A438C95B6CAA724BC9F3DEB9CD1E530031B038AA)
        hashed subpkt 2 len 4 (sig created 2022-08-12)
        hashed subpkt 27 len 1 (key flags: 0C)
        hashed subpkt 9 len 4 (key expires after 2y0d13h50m)
        subpkt 16 len 8 (issuer key ID CD1E530031B038AA)
        data: [256 bits]

Some details about TestKey3:

$ gpg --show-keys backup_2022-08-11.sec
pub   rsa3072/BBF1585AFE6385A9 2022-08-12 [SC]
      4AFA1B0808A82E3EF941B067BBF1585AFE6385A9
uid                            TestKey3 <TestKey3@Email>
sub   rsa3072/F3E9DFE37D777AEF 2022-08-12 [E]

$ gpg --list-packets backup_2022-08-11.sec
# off=0 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
        version 4, algo 1, created 1660270696, expires 0
        pkey[0]: [3072 bits]
        pkey[1]: [17 bits]
        keyid: BBF1585AFE6385A9
# off=400 ctb=b4 tag=13 hlen=2 plen=25
:user ID packet: "TestKey3 <TestKey3@Email>"
# off=427 ctb=89 tag=2 hlen=3 plen=432
:signature packet: algo 1, keyid BBF1585AFE6385A9
        version 4, created 1660270696, md5len 0, sigclass 0x13
        digest algo 10, begin of digest 74 04
        hashed subpkt 11 len 3 (pref-sym-algos: 9 8 7)
        hashed subpkt 21 len 1 (pref-hash-algos: 10)
        hashed subpkt 22 len 1 (pref-zip-algos: 1)
        hashed subpkt 25 len 1 (primary user ID)
        critical hashed subpkt 2 len 4 (sig created 2022-08-12)
        critical hashed subpkt 30 len 1 (features: 01)
        critical hashed subpkt 27 len 1 (key flags: 03)
        subpkt 16 len 8 (issuer key ID BBF1585AFE6385A9)
        data: [3070 bits]
# off=862 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
        version 4, algo 1, created 1660270696, expires 0
        pkey[0]: [3072 bits]
        pkey[1]: [17 bits]
        keyid: F3E9DFE37D777AEF
# off=1262 ctb=89 tag=2 hlen=3 plen=415
:signature packet: algo 1, keyid BBF1585AFE6385A9
        version 4, created 1660270696, md5len 0, sigclass 0x18
        digest algo 10, begin of digest 87 0c
        critical hashed subpkt 2 len 4 (sig created 2022-08-12)
        critical hashed subpkt 27 len 1 (key flags: 0C)
        subpkt 16 len 8 (issuer key ID BBF1585AFE6385A9)
        data: [3071 bits]

Observations:

TestKey1 (gpg 2.3) is an ECC-key (ed25519/cv25519) while TestKey3 (OpenKeyChain) is an RSA-key (rsa3072). I assume that OpenKeyChain supports ed25519/cv25519.
TestKey1 (gpg 2.3) states that it supports some advanced OpenPGP features: features: 07 (= 0x04 + 0x02 + 0x01).
TestKey3 (OpenKeyChain) states that it only supports one advanced OpenPGP feature: features: 01

Because TestKey1 states that the key supports the "AEAD Encrypted Data" (feature 0x02) feature, gpg makes use of this feature if you encrypt something with TestKey1.

Please read https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.24 to understand how the features are used for provide interoperability between different implementations of OpenPGP.

If you try to use a key that states a feature that one of the OpenPGP implementations you use doesn't support, then that's your own fault. Simply use the keys you have created with OpenKeyChain and that don't state that AEAD is supported an be done with it.

If modern OpenPGP implementations couldn't use modern features, we'd still be stuck with whatever algorithms and features PGP 2 supported.

As an alternative you may change the preferences on the key to adjust them to your changed/downgraded version.

That should be done with the implementation lacking the features of GnuPG; I don't know whether OpenKeyChain supports this, though.

Here is an example on how to remove the AEAD preference from a key using GnuPG 2.3:

$ gpg --edit-key someone@g10code.com
Secret key is available.

sec  brainpoolP384r1/AF99952165A3D8C5
     created: 2022-04-14  expires: 2028-08-15  usage: SC
     card-no: 0006 15493264
     trust: unknown       validity: unknown
ssb  brainpoolP384r1/FFB6A9DC972C60D4
     created: 2022-04-14  expires: never       usage: E
     card-no: 0006 15493264
ssb  ed25519/24BAEDD72506F974
     created: 2022-04-14  expires: never       usage: A
     card-no: 0006 15493264
[ unknown] (1). someone@g10code.com

gpg> showpref
[ unknown] (1). someone@g10code.com
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify

gpg> pref
[ unknown] (1). someone@g10code.com
     S9 S8 S7 S2 A2 H10 H9 H8 H11 H2 Z2 Z3 Z1 [mdc] [aead] [no-ks-modify]

gpg> setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z2 Z3 Z1 mdc no-ks-modify
Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) n

@werner @ikloecker I tend to agree with the original reporter that this is an issue. Not a Bug, but an issue that causes problems for our Users. At least we should have some way in Kleopatra to disable "Advanced Features". Then users could be pointed to some screenshots how to disable AEAD.

My argument would be that it is impossible for the target audience of Gpg4win and OpenKeyChain to create interoperable Keys between them with Gpg4win and that is not nice.

Hello All,

Thank you for your help and your thoughts.

I imported TestKeys 3 and 4 into gpg4win by following the instructions in the faq of OpenKeyChain.
Here is a screenshot of Kleopatra after that import.

Then, by copy and pasting from the instructions from Werner, I changed the prefs for TestKey1 and TestKey2.

Next I created two pdf test files, TestFileA.pdf and TestFileB.pdf
Here are the unencrypted files:

TestFileA.pdf6 KBDownload

TestFileB.pdf6 KBDownload

I signed TestFileA.pdf with TestKey1 encrypted for TestKey2

Here is the encrypted file:

TestFileA.pdf.gpg3 KBDownload

I signed TestFileB.pdf with TestKey3 encrypted for TestKey4

Here is the encrypted file:

TestFileB.pdf.gpg4 KBDownload

Next, I imported TestKey1 and TestKey2 into OpenKeyChain.

Then I emailed the encrypted TestFileA from Desktop to Smartphone, and
I emailed the encrypted TestFileB from Desktop to Smartphone.

I received both files in my smartphone email and I saved both files to my smartphone.
Then I tried to decrypt each file.

With encrypted TestFileA I get
X Encountered an error reading input data!
Processing input data
Attempting to process OpenPGP data
Encountered an error reading input data!

With encrypted TestFileB I get
Unknown filename (touch to open)
When I touch the filename I get
X No valid OpenPGP encrypted or signed data found!
Processing input data
Attempting to process OpenPGP data
Starting decrypt operation
Preparing streams for decryption
Processing cleartext data
No valid OpenPGP encrypted or signed data found!

So, it still does not work for me.

Please advise me what to try next.

Thank you for your help.
GPGNewbie9000.

$ gpg --list-packets TestFileA.pdf.gpg 
gpg: encrypted with ECDH key, ID 8594A0FBC4AFAF88
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 8594A0FBC4AFAF88
        data: [263 bits]
        data: [392 bits]
# off=96 ctb=d4 tag=20 hlen=2 plen=0 partial new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
        length: unknown

-> This still uses AEAD. It seems Werner's method to remove the AEAD feature doesn't work. At least not with gpg 2.3.7.

$ gpg --edit-key 8594A0FBC4AFAF88
Secret key is available.

sec  ed25519/24C247E122ACA897
     created: 2022-08-12  expires: 2024-08-11  usage: SC  
     trust: unknown       validity: unknown
ssb  cv25519/8594A0FBC4AFAF88
     created: 2022-08-12  expires: 2024-08-11  usage: E   
[ unknown] (1). TestKey2 <TestKey2@Email>

gpg> showpref
[ unknown] (1). TestKey2 <TestKey2@Email>
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify

gpg> pref
[ unknown] (1). TestKey2 <TestKey2@Email>
     S9 S8 S7 S2 A2 H10 H9 H8 H11 H2 Z2 Z3 Z1 [mdc] [aead] [no-ks-modify]

gpg> setpref S9 S8 S7 S2 A2 H10 H9 H8 H11 H2 Z2 Z3 Z1 mdc no-ks-modify
Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify
Really update the preferences? (y/N)

As you can see the new preference list still includes AEAD: OCB. I have no idea why it worked for Werner. Maybe it requires his most recent commit rG1908fa8b835c: gpg: Improve --edit-key setpref..

I have no idea why OpenKeyChain cannot decrypt TestFileB.pdf.gpg. Here is the packet list (with automatic decryption).

$ gpg --list-packets TestFileB.pdf.gpg
gpg: encrypted with rsa3072 key, ID B29C3E00B6EF27FA, created 2022-08-12
      "TestKey4 <TestKey4@Email>"
# off=0 ctb=85 tag=1 hlen=3 plen=396
:pubkey enc packet: version 3, algo 1, keyid B29C3E00B6EF27FA
        data: [3071 bits]
# off=399 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
        length: unknown
        mdc_method: 2
# off=420 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=422 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid BBF1585AFE6385A9
        version 3, sigclass 0x00, digest 10, pubkey 1, last=1
# off=437 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
        mode b (62), created 1660319025, name="",
        raw data: unknown length

Comparing this to the encrypted key backup created by OpenKeyChain, I noticed the unknown length and the partial attribute of the encrypted data packet. I have no idea whether this is relevant.

Dear ikloecker,

Thank you for your ongoing research and help.
Hopefully, werner or aheinecke or another forum contributor will have additional ideas that can help solve these mysteries.

Thanks,
GPGNewbie9000

Interoperability Issue Between gpg4win - Kleopatra and OpenKeyChainClosed, WontfixPublicActions

Description

Details

Related Objects

Event Timeline

Interoperability Issue Between gpg4win - Kleopatra and OpenKeyChain
Closed, WontfixPublic
Actions