Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[kho]

Very interesting question indeed, Tony!

On 8/27/22 15:17, Tony Lee via Gnupg-users wrote:
> 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
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users