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@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
