Using libgcrypt and a library using it

[Jean-Philippe Garcia Ballester]

On Monday 16 January 2006 16:40, Werner Koch wrote:
> On Sun, 15 Jan 2006 18:00:36 +0100, Jean-Philippe Garcia Ballester said:
> >   gcry_control(GCRYCTL_INIT_SECMEM,524288,0);
>
> Are you really sure that you need 512k for secure memory?  The
> algorithm to maintain that memory area is not very advanced and too
> many allocs/frees may slow those oeprations down.

I'm not sure at all, and I would really much appreciate some explanations or 
advices, since I'm not an expert programmer, and I'm not sure to understand 
what should be in secure memory and what should not.
We're developping a ssh library. I just made the port from libcrypto to 
libgcrypt, so for now, secure memory is only used with hashes and ciphers. Is 
this needed? It seems to me that encrypted packets are not highly 
confidential. I did not change the allocations for structures containing 
cryptographic keys, but shouldn't they be in secure memory? It seems also 
that hashes used in DH handshake should be in secure memory to, shouldn't 
they?
What secure memory is needed, considering that we have no limitation on the 
number of ssh connections?
I'm sorry to bother you, but some explanation would be of much help. I'll also 
take a look a the gsti library, but I'm not sure I'll understand why things 
are in secure memory or not.

>
> > The possibility to check if secure memory has been initialize and if
> > there's enough and the possibility to initalize secure memory and adjust
> > the size of secure memory after the call to
> > gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0) would prevent users to
>
> That is unfortunately not possible.  The whole mess with mlocking is
> that under Linux you need to have root rights or appropriate
> capabilities.  After the initialization Libgcrypt will relinquish
> these permissions (unless you are running under root).  There is at
> least one assertion to make sure that rights have been dropped.
>
> These mlock restrictions are really silly given that there so many
> other ways of eating up resources.  The new approach to allow for a
> certain amount of locked memory seems to be more sensible to the
> problem but as of now we can't rely on it.

Thanks a lot for this clear answer.

-- 
Jean-Philippe Garcia Ballester
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20060116/254af81e/attachment.pgp