[RFC PATCH] enable configurable SECMEM_BUFFER_SIZE

[Shah, Amul]

[amul] Hi, please excuse any Outlook reformatting.

From: Gnupg-devel [mailto:gnupg-devel-bounces at gnupg.org] On Behalf Of Werner Koch Sent: Wednesday, November 22, 2017 9:47 AM

>On Tue, 21 Nov 2017 19:12, matthew.summers at syapse.com said:
>
>> id. This is a severe issue for us that seems pretty easy to remedy
>> with a patch like this.
>
>Can you please explain the problem you try to solve.

[amul] Similar to Matt, we're trying to use GnuPG to decrypt secret keys. If I
understood Matt's problem, they use 4k keys which exhaust the mlock()ed space
very fast. With fis-gtm, we spawn so many processes that exhaust
mlock()ed space frequently enough for this to be a problem for us.


>Most crypto operations which temporary require allocation of extra chunks of
>data (big integer computation) the secure memory area is enlarged on the fly.
>
>The gpg-agent stores secret keys in a cache which is allocated in standard
>memory.  This can be done because the keys are stored encrypted in this cache
>(using a per process ephemeral key).

[amul] "secure" memory allocations only use the first mlock()ed memory area. Is
this what you mean by "standard memory"?

[amul] When you say that the agent can cache a secret key, does that mean
subsequent requests for the same key will be serviced from cache?


>Any problems creating or using more keys is either due to a memory leak in
>gpg-agent or because you have a lot of active connections to the gpg-agent
>using private keys.

[amul] In our case, we have many active connections to the gpg-agent (via
 libgpgme and gpg) as processes decrypt the secret key that encrypts the
fis-gtm database.


>For that latter case there are two solutions:
>
> 1. Enlarging the secure memory area.  This has the problem that you
>    will never known how much is sufficient.
>
> 2. Enlarge the secure memory area on the fly as we do it with some of
>    the Libgcrypt internal mallocs (actually all xmalloc style
>    allocations).  That would require an update to Libgcrypt and a
>    runtime option to gpg-agent to enable this.

[amul] I agree with your assessment of option #1. I think, however, that there
is a third option. In its current form, the gpg-agent accepts every request and
spawns a thread to handle it. There is no limit on the rate at which it accepts
connections. Other than crudely limiting the thread count, I don't know of a
good way to slew the agent. Do you have any suggestions? Additionally, I have
not seen any timeouts in gpg/libassuan when communicating with the gpg-agent.

[amul] If I were to prepare a patch for option #2, assuming it passes a review and
conforms to the coding standards, would it be acceptable?

[amul] Best Regards, Amul
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.