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