Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Jacob Bachmeyer]

Tony Lee via Gnupg-users wrote:
> [...]
>
> 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).

KDF here is "Key Derivation Function", not "Key Distribution Function".

> However, in my Aug 30 response, I noted that I had carefully followed 
> the gpg man pages in specifying my wish to use an AES256 cipher, and 
> an SHA256 hash function.

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.

> [...] As I noted, both AES-128 and SHA-1 are generally deprecated 
> functions in cryptography.

This is completely irrelevant to a KDF.  The only purpose of a KDF is to 
expend considerable computational power to derive a key from a 
passphrase, to partially compensate for the expected low entropy of a 
passphrase by making a search dramatically more expensive.

> So I am left wondering whether my specified AES-256 and SHA-256 were 
> used with my other count_value values.

Most probably yes, although you would need to examine the source code to 
be certain.  GPG 1.4 *did* support AES256 and SHA256, so compatibility 
would not be an excuse to fail to use them.

> My Aug 27 submission highlighted a Spectra Secure YouTube which noted 
> that the --s2k parameters were ignored for key export without warning, 
> and that this "bug" had been the case since 2017.  Do we now discover 
> that the --s2k parameters are similarly ignored for _all_ symmetric 
> encryption procedures, in contradiction to the man-page instructions 
> on use?

If so, that would be a very serious bug, but you would need to examine 
the sources to make sure.


-- Jacob