Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Tony Lee]

TL > I was pleased to receive a rapid response from Werner Koch, who 
explained that the nominated count_value of 1024 actually used a default 
count_value compatible with gpg 1.4, and then went on to explain that 
OpenPGP used an SHA1-based Key Distribution Function (KDF).

Jacob B > KDF here is "Key Derivation Function", not "Key Distribution 
Function".

You are correct: not sure how this happened. My original submission 
reflected a "Notes" paper I had been writing (for my own clarification) 
which included an acronyn list with the correct expansion. I guess this 
confirms my status as a non-expert, which is why I "Seek Assurance"!


Jacob B > If I understand correctly, it probably did:  your data was 
encrypted using AES256 using a key derived from your passphrase using 
the OpenPGP KDF and an integrity check value using SHA256 was included 
with the encrypted data.

That was certainly my intention, using:

time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \
--s2k-count count_value cleartext_file

where the man gpg states:

--s2k-cipher-algo name
               Use name as the cipher algorithm for symmetric encryption 
with a passphrase

--s2k-digest-algo name
               Use name as the digest algorithm used to mangle the 
passphrases  for  symmetric  encryption.
               The default is SHA-1.
--s2k-count n
               Specify how many times the passphrases mangling for 
symmetric encryption is  repeated.   This
               value may range between 1024 and 65011712 inclusive.

Werner noted [for Count 1024] For backward compatibility reasons with 
1.4 the default count value is used in this case [and] You can't compare 
some AES-KDF to the SHAl based KDF of OpenPGP. The --s2k options mention 
"mangling passphrases" which sounds exactly like a KDF, but a default 
SHA-1 was used in one case, at least.

TL > My Aug 27 submission highlighted a Spectra Secure YouTube (dated 29 
Nov 2021) which noted that the --s2k parameters were ignored for key 
export without warning, and that this "bug" had been the case since 2017.

Jacob B > ... that would be a very serious bug ...

The Spectra Secure YouTube was: 
https://www.youtube.com/watch?v=j-qBChKG15Y "Password Managers: The Case 
Against GNU pass (feat gpg)". Around minute 4:31 it explains very 
clearly that the --s2k settings do not work (when exporting a key), 
showing screen evidence. In a later comment, Spectra Secure quotes 
"additional context on reddit" from skeeto at: 
https://www.reddit.com/r/commandline/comments/r4ndi9/comment/hmjbkmc/ , 
which states: "The exported S2K protection is different than than the 
protection used on the keyring, so you can't infer anything about GnuPG 
keys at rest unless you're storing them in exported format rather than 
on your keyring. This changed in GnuPG 2.1, and that's why the S2K 
options are silently ignored as of GnuPG 2.1. I'm the person who filed 
the bug report discussed in the video, and the responses to that report 
are how I learned what's going on.".  This implies the "silent ignoring" 
is correct for exported keys, but may not be relevant to other 
functions. We now seem to find it can be relevant to other activities as 
well.

In fact, all I can really infer is that practice does not match the man 
gpg, so it is difficult to decide what is (or should be) going on.

I am not really in a position to examine the sources with any 
confidence, but would welcome suggestions for software which would 
permit me to check what was set up.  Does John the Ripper (gpg-opencl), 
plus hashcat, detail the algorithms used, having broken a password?

Tony