Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Tony Lee]

I have recently been seeking assurances on protection of sensitive
data on my SuSE Leap 15.4 system, and protection of passwords.

Issues discussed concern gpg2 2.2.27-150300.3.5.1, and keepassxc
2.7.1-bp154.3.3.1; together with hypothetical queries on Youbikey as
libykpers-1-1 1.19.0-4.19.


Protection of Symmetric passwords (or passphrases) usually involves a
Key Distribution Function (KDF) which "mangles" the User password to
produce the "master key" which is actually used to encrypt sensitive
material. The KDF is deliberately designed to be slow (eg thousands to
millions of AES-256 rounds) and, more recently, also designed to
require substantial memory (eg Argon2). This is to slow brute-force
attack on passphrases (which may have limited entropy to permit
memorability), and (more recently) to limit the use of GPU and/or
ASIC-based brute-force attack.

The KeePass password safe
(https://keepass.info/help/base/security.html) helpfully describes its
security features, such as encryption of whole database, random-salted
adjustable KDF (multiple AES-256, or Argon2; together with timing of
KDF function --- eg 1 second). When running: sensitive data stored
encrypted in secure process memory, and over-writing such memory
before release. Internal viewer/edit available, which avoids putting
data onto disk. Anti-keylogger facilities --- although additional
hardware may be needed to protect against hardware-based keyloggers
located between keyboard and computer.

Uncertainty: Does a Yubikey make a KeePass pasword available through
secure process memory? Can anyone point me to a description?

Having discovered encrypted PDFs are essentially broken
(https://www.kaspersky.com/blog/36c3-pdf-encryption/33827/), I have
been looking more carefully at encrypted archive formats, both for
communication and storage (eg of PDF files), and both during User use
and for 'data at rest' --- which may be vulnerable to hacking.

As a long-time user of GnuPG, with hindsight I am now concerned at
having failed to find any description of GnuPG security aspects
similar to that above for KeePass. Perhaps these security requirements
are so obvious they do not need describing explicitly, but the cynic
in me would like to see something more concrete.

Worryingly, the Enigmail Handbook
(https://www.enigmail.net/documentation/Enigmail_Handbook_1.8_en.pdf
Section 8.2) merely notes `You should be aware ... that your encrypted
mails are as safe as allowed by the computer you use Enigmail on. ...
If your computer is infected with a key logger and a malware that
grants an intruder remote access on your files, all the cryptographic
robustness of OpenPGP and the strongest passphrase won't protect your
messages from being snooped or falsified'. This sounds like a 'Counsel
of Perfection' which is not particularly helpful.

Does anyone know of a clear description of security aspects in GnuPG,
comparable to that above for KeePass?

On 29 Nov 2021, Spectra Secure noted
(https://www.youtube.com/watch?v=j-qBChKG15Y , starting 2:00) that
although gpg has '--s2k' settings that are supposed to change the weak
default (cipher, digest hash, and digest-hash rounds-count) algorithms
from AES-128, SHA-1 and a low count --- for key export --- it will
ignore these setting without even giving a warning. A bug-report has
been in place since 2017, although this has never been fixed. However,
a subsequent comment (from skeeto on reddit) suggested that the
'export' gpg protection differed from that of the keyring, so you
cannot infer a problem with conventional use of the keyring.

OK, so I have been doing a little experimentation. Using the KeePass
KDF timing of AES-KDF, my 2011 12-thread processor i7-3930K CPU at 3.2
GHz (CPUMark 8,247) performs a KDF of 23,400,000 AES-KDF rounds in
1.0~s (and time was proportional to the number of rounds). This is a
highly serial process, so must be performed on a single thread. In
principle, this processor could achieve (say) 12 X 23,400,000 =
280,800,000 AES-256 rounds in 1~s while brute-forcing 12 potential
passwords. The 2021 i7-12700K (CPUMark 34,460: 4.2-fold faster),
costing less than GBP 400, could in principle achieve one billion (one
thousand million) AES-256 rounds per second --- and faster speeds
would be available from multiple processors, GPUs, or ASIC-based
devices.

We now time the encryption of a 28 Byte or 565 kByte plaintext file,
with various 'count' values via:

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

with a short 11-character password. In practice, although we are
timing an encryption, for high 'count' values the KDF process will
dominate timing, and the known password details will be irrelevant. We
present only User time, as System time is negligible:

Some results are:
For 28 Byte cleartext:

Count			User Time (s)
    1024		0.237
  131072		0.005
 2097152		0.013
65011712		0.320

For 565 kByte cleartext:

Count			User Time (s)
    1024		0.245
  131072		0.020
 2097152		0.033
65011712		0.341

We see the cleartext length is not greatly significant, especially at
higher count values, but the User Time is nowhere near linear with
count --- which one would expect. For a count of 65,011,712 rounds,
the Time is around 0.33 seconds. On the same machine, 23,400,000
AES-KDF rounds were completed in 1.0~s (with a linear relationship),
implying that at the s2k maximum count of 65,011,712, the gpg code is
a factor of (65,011,712 / 0.33) / (23,400,000 / 1.0) = 8.4 times
faster than the KeePass code, with much smaller factors for lower
count values. This all sounds highly inconsistent and suspicious ---
and the lengthy timing for a count of 1024 is completely unexplained.

It is difficult to avoid the suspicion that the s2k parameters are not
doing what is stated in the info gpg. In particular, it is unclear
whether the gpg KDF is protecting the master key as expected.

This sounds like a bug. Can anyone explain what is happening?

If a Yubikey is used to store the User passphrase for gpg, is it
passed to the gpg code via secured memory which is overwritten before
close-down?

I am hoping someone will be able to help me on these points.


Tony