Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Tony Lee]

On Aug 27 I submitted a query to this mailing list on the same Subject 
as headed here, with further details on the software used.

Specifically, I timed the encryption (primarily the KDF aspect) of 
alternative cleartext_files with various legal count_value values (1024, 
131072, 2097152, 65011712) as:

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

I was surprised to find that count_value of 1024 gave a timing nearly as 
long as that for 65011712.

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).

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. The count_value of 1024 clearly ignored my wishes
on hash function (for gpg 1.4 compatibility), and --- I must assume --- 
also used AES128 cipher for the same reason. As I noted, both AES-128 
and SHA-1 are generally deprecated functions in cryptography.

So I am left wondering whether my specified AES-256 and SHA-256 were 
used with my other count_value values. 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?

My earlier submissions noted that KeePass (password safe) gave an 
encouraging oversight of how areas of memory were secured from other 
applications while KeePass is in use, giving a degree of protection from 
malware etc., or having critical data finding its way onto disk storage 
--- ready for scrutiny my a later hacker.  I sought a similar oversight 
on gpg --- perhaps based on the KeePass template. I noted the 
possibility that such techniques were so obviously necessary that 
(perhaps) there was little point in describing them.

The response that I have seen merely implied that such oversight would 
take a lot of effort to write, and may be less helpful than expected. 
This suggests to me that these "obviously necessary" techniques were 
_not_ being implemented (or even attempted), and that the only solution 
was to fully ensure the security of your entire system. I see this as a 
"Counsel of Perfection" that may only be practical with an air-gapped 
system that has had no data input from the internet. My understanding is 
that Security is something typically applied in layers, with the full 
knowledge that any single layer is unlikely to be perfect.

The concept that no thought may be given within gpg to the protection of 
passwords, and that deprecated cryptographic functions may be in use 
(despite commands to the contrary), seems to me to be highly disturbing.

Tony