Files encrypted on another platform using password based encryption (-c) intermittently fail to decrypt on Kleopatra
Open, NormalPublic

Description

Hello,
I am using password based encryption (-c) using an IBM product called Encryption Facility (EF). I have encrypted a file using EF with the following OpenPGP commands and when using Kleopatra (Version 3.1.8-gpg4win-3.1.8 on Windows 10) to perform the decryption, sometimes it works and sometimes it does not.

I encrypt the same file, with the same openPGP commands and using the same passphrase. When I decrypt this file using EF it always decrypts successfully, however with Kleopatra, a file that fails to decrypt may decrypt the next time I try to decrypt it. Or a file that successfully decrypts with Kleopatra may fail to decrypt the next time.

Here are the OpenPGP commands used for encryption:
-o '/home/suimgwy/_input.pbe'
-s2k-cipher-name AES_256
-s2k-digest-name SHA256
-s2k-mode 3
-s2k-passphrase dave
-t ISO-8859-1
-use-mdc
-c '/home/suimgwy/_input.txt'

_input.txt file contains 1 line of data: Testing using password based encryption.

When the encrypted _input.pbe file fails to decrypt, I renamed the encrypted file to: decryption.failed.pbe
These are the messages that are seen after clicking "Diagnostics"
gpg: AES256 encrypted session key
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key

When the encrypted _input.pbe file decrypts successfully, I renamed the encrypted file to: decrypted.ok.pbe.
The file that decrypted successfully yesterday failed to decrypt once today. Here are the Diagnostic messages when it failed to decrypt:
gpg: AES256 encrypted session key
gpg: encrypted with 1 passphrase
gpg: key setup failed: Invalid key length
gpg: decryption failed: Invalid key length

Here is the --list-packets for decryption.failed.pbe

C:\userfiles\EF\GnuPG\>gpg --list-packets _decryption.failed.pbe
gpg: AES256 encrypted session key
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key
# off=0 ctb=c3 tag=3 hlen=2 plen=38 new-ctb
:symkey enc packet: version 4, cipher 9, s2k 3, hash 8, seskey 192 bits
        salt 65303373C42692B1, count 1507328 (167)
# off=40 ctb=d2 tag=18 hlen=2 plen=107 new-ctb
:encrypted data packet:
        length: 107
        mdc_method: 2

Here is the --list-packets for decrypted.ok.pbe

C:\userfiles\EF\GnuPG\pmr_michal>gpg --list-packets _decrypted.ok.pbe
gpg: AES256 encrypted session key
gpg: encrypted with 1 passphrase
# off=0 ctb=c3 tag=3 hlen=2 plen=38 new-ctb
:symkey enc packet: version 4, cipher 9, s2k 3, hash 8, seskey 192 bits
        salt 5B4295D0D11177A0, count 98304 (104)
# off=40 ctb=d2 tag=18 hlen=2 plen=107 new-ctb
:encrypted data packet:
        length: 107
        mdc_method: 2
# off=53 ctb=cb tag=11 hlen=2 plen=72 new-ctb
:literal data packet:
        mode t (74), created 1560362253, name="/home/suimgwy/_input.txt",
        raw data: 42 bytes

I will attach both encrypted files. The password is dave. I would like to know what is wrong with the file (_decryption.failed.pbe) that fails to decrypt. You will not be able to reproduce unless you have the IBM Encryption Facility product but I can reproduce.

Thanks for looking into this!
Regards,
Dave Hilliard
dhilliar@us.ibm.com

mrdave19 created this task.Jun 14 2019, 1:55 AM
werner updated the task description. (Show Details)Jun 14 2019, 11:47 AM
mrdave19 renamed this task from Files encrypted on another platform using password base encryption (-c) intermittently fail to decrypt on Kleopatra to Files encrypted on another platform using password based encryption (-c) intermittently fail to decrypt on Kleopatra.Jun 19 2019, 3:40 PM
mrdave19 updated the task description. (Show Details)
aheinecke triaged this task as Normal priority.Mon, Jul 1, 2:29 PM
aheinecke added subscribers: werner, aheinecke.

back from vacation so apologies for the delay. @werner This is reproducible on the command line without Kleopatra. So maybe something for you our Gniibe to look into?

@mrdave19 You are hopefully a 1000% sure that the passphrase for _decryption.failed.pbe is "dave" without the quote marks. We will waste a lot of time if you just had a typo when entering the passphrase for the _decryption.failed.pbe file.
I can decrypt the "decryption ok" file with that passphrase.

Welcome back from vacation!
@aheinecke Yes I am 1000% sure the passphrase is "dave" without the quotes.
These are the commands I use for the encrypt using the IBM Encryption Facility:

-o '/home/suimgwy/_july1.pbe' \
-s2k-cipher-name AES_256 -s2k-digest-name SHA256 -s2k-mode 3 \
-s2k-passphrase dave \
-t ISO-8859-1 \
-use-mdc \
-c '/home/suimgwy/_input.txt'
<<<

I just recreated this again today.
On the first test, _july1.pbe' decrypted successfully using kleopatra.
I encrypted again (calling the encrypted file _july1a.pbe) and that failed to decrypt using kleopatra.
Both encrypted files (_july1.pbe and _july1a.pbe) decrypted successfully using the IBM Encryption Facility.
Here are the diagnostic messages:
gpg: AES256 encrypted session key
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key


I'll upload _july1.pbe and _july1a.pbe

That won't be easy to debug unless we have intermediate debug values from the generating implementation. That IBM Encryption Facility looks partly similar in the command line options to gpg so I wonder whether it will be possible to get some debug output. @mrdave19: we can continue by private mail in case that is helpful for you (wk at g10code com)

werner moved this task from Backlog to Deferred on the gnupg (gpg22) board.Wed, Jul 3, 6:14 PM
gniibe added a subscriber: gniibe.Thu, Jul 11, 9:59 AM

While I only observed the output of --list-packet, what I see are:

(1) the salt is odd in the failure file. (even in the success file)
(2) count is higher in the failure file.

Can you specify --s2k-count with smaller value, and what's going on?

If I were testing more, I would generate many (say, 1000, or more, for example) encrypted message by the tool (IBM Encryption Facility), to examine by GnuPG and figure out some patterns of failure.

I wonder the reason why s2k encoded count is so different (49, 104: success, 167, 173: failure).

@gniibe: We move this issue over to mail. I'll forward it to you.