On 2019-02-26 at 11:02 +0200, Ciprian Dorin Craciun wrote: > Hello all! > > Given the recent survey in password managers security [1], which > concluded with their failure to properly sanitize / scrub the > sensitive data (i.e. "master key") in "running locked state", I was > wondering how does GnuPG Agent fare in this regard? > > More specifically: > * let's assume that one uses GnuPG Agent; (only for PGP;) > * the user enters the password for a particular private key; > * (one assumes that the password was used to get the private key > cryptographic material, and then scrubbed;) > * then `--max-cache-ttl` seconds passes; > * one assumes that the private key cryptographic material is now scrubbed; > > Is this expectation correct?
I would say this is the right expectation. However note that even with a perfect agent implementation, you might find eg. that the kernel swapped to disk the page where the password was read (before providing it to the program, which would hopefully be using mlock(2) to avoid being swapped itself). > Is there some external analysis about the security of the agent with > regard to the scrubbing of both passwords and cryptographic material? Intrigued by this I did a quick glance at the relevant code: The cache purging seems to be done at housekeeping() [1], which simply calls release_data over the entry to free. In turn, release_data() [2] is just a xfree() call, which would be converted to gcry_free(), which is a libgcrypt function that will call _gcry_private_free() [3]. _gcry_private_free() checks[4] whether this allocation was from a secure pool (ie. allocated with gcry_xmalloc_secure), in which case it will call _gcry_secmem_free[5], which does attempt to wipe the memory by overwriting it with 0xff, 0xaa, 0x55 and 0x00 [6] using the macro wipememory2,[7] which may do so inline (using volatile to avoid compiler optimization) or end up calling _gcry_fast_wipememory, which would end up calling the normal memset() through a function pointer.[8] (I would expect either an attempt to use memset_s if available, similar to the check for explicit_bzero, or a note that like SecureZeroMemory it provides no benefit, instead of a plain memset, though) Best regards [1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/cache.c;h=799d595abdb007422090622a959aa03741139c54;hb=HEAD#l198 [2] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/cache.c;h=799d595abdb007422090622a959aa03741139c54;hb=HEAD#l141 [3] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=src/global.c;h=d82c680a5d2a2981129d0531ff43b337ffebb085;hb=refs/heads/master#l1019 [4] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=src/stdmem.c;h=04ce64fba14b2fd5d58be5050b80d6a159dffed5;hb=refs/heads/master#l220 [5] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=src/secmem.c;h=b36c44f6de188ff005ca10800a4ba9fdf5a352d2;hb=refs/heads/master#l787 [6] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=src/secmem.c;h=b36c44f6de188ff005ca10800a4ba9fdf5a352d2;hb=refs/heads/master#l768 [7] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=src/g10lib.h;h=694c2d83e2682103d83be03070c737a1bb6a3ae4;hb=refs/heads/master#l337 [8] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=src/misc.c;h=bb39e1c2fe1c94affe1f024a87621f79e77ba1aa;hb=refs/heads/master#l504 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users