Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Oct 13 19:42:09 CEST 2017
On Fri 2017-10-13 15:00:00 +0200, Andreas Stieger wrote:
> I would like to point out that this creates an issue on systems with the
> max locked memory size (ulimit -l) is limited to 64k:
> gpg: Warning: using insecure memory!
> mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory)
> Thus exposing private key material to being swapped out to permanent
> storage. I am not sure if a mere warning is sufficient here.
there are (at least) three ways that your RAM could be non-ephemeral
that you don't get any warnings about at all:
* "cold boot" attacks -- not all DRAM is actually fully wiped just
because power is removed from it.
* hibernation -- if your computer suspends to disk, it doesn't matter
than the memory was locked.
* virtual machines -- if you are running gpg inside a virtual machine
of any type, it's possible that the memory of the virtual machine is
subject to monitoring or recording from the host.
Also, any sensible use of swap today on any machine that has sensitive
data should be done with an ephemerally-encrypted swap device. In
particular, on GNU/Linux systems with cryptsetup, that means something
* a line which creates the mapped device and runs mkswap on it, in
cswap /dev/sda6 /dev/random swap
* and a line which points to that newly-mapped device in /etc/fstab:
/dev/mapper/cswap swap swap defaults 0 0
So for me, it's not clear that even the warning about not using locked
memory itself is warranted, and i suspect that any requirement to use
locked memory today would inhibit the use of crypto more than it would
avoid the risk of leaks.
Also, the use of locked memory feeds into these interminable discussions
about "how much is enough?" which is time that we could spend on fixing
usability instead :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Gnupg-devel