Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576

[Matthew Summers]

On Fri, Oct 13, 2017 at 8:00 AM, Andreas Stieger <astieger at suse.com> wrote:

> Hello,
>
>
> On 10/13/2017 06:44 AM, Matthew Summers wrote:
> > This is following up on an issue that started around in the 2.1.17
> > days, and I have been carrying a small patch addressing this for my
> > team since we figured it out. This is all documented in an earlier set
> > of threads to this ML.
> >
> > Would you consider increasing SECMEM_BUFFER_SIZE to 1048576 in the
> > case where the configure option `large_secmem` = yes, please?
> >
> > The patch itself is a super trivial in both configure and/or
> > configure.ac <http://configure.ac>.
> >
>
> You haven't explicitly referenced the rationale for this. Is this about
> RSA keys in excession of 4096 bits?
>

Yes, we are using 4096bit RSA keys, and generally recommend/require that
internally at this stage in the game.

Here is the start of the 1st thread:
https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032486.html

Here is the start of the 2nd thread:
https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html

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.


I have been adjusting this ulimit as a matter of course, so it's not been
an issue. It appears that 64k 'default' max locked memory and/or max memory
size may vary from distro to disto as well.

I would like to stress that this is not a theoretical problem we are
dealing with, but rather an issue that were we not able to patch
the SECMEM_BUFFER_SIZE we would not be able to use GnuPG to protect
sensitive data as we currently do (via saltstack).

What about an extra arg in configure.ac that would let us either specify
the SECMEM_BUFFER_SIZE or set it with `--extra-large-secmem`? I'd be happy
to provide a patch for that, of course.

Thanks,
Matt Summers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20171020/814c4abe/attachment.html>