Using libgcrypt and a library using it

[Werner Koch]

On Mon, 16 Jan 2006 18:29:01 +0100, Jean-Philippe Garcia Ballester said:

> 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 

I can';t tell.  It depends on your threat model.

> confidential. I did not change the allocations for structures containing 
> cryptographic keys, but shouldn't they be in secure memory? It seems also 

It depends on the keys and whether you expect atatckers to be able to
read the swap space.  For session keys and DH secrets I doubt that it
is needed at all.

> 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.

GSTI does not make use of secure memory at all.  However Libcgrypt
itself uses secure memory for certain operations.  Thus there is a way
to initialize it; that code is pretty old and not as it should be.

What you should do ist to decide whether there are any long living
keys (host key, user key) and they are sensible enough to have an
extra protection.  In this case, use gcry_malloc_secure for these
secret keys.  I'd do that.

For session keys, MACs and such I doubt that under common threat
models it makes sense to use this secure memory.  One advantage of the
secure memory is that the gcry_free will overwrite the release memory
and saves you a "burn" call.  For failsafe reasons I tend to add a
burn call anyway before doing a free - if I know that the releaed
memory has sensitive data and I know the size of the memeory block at
that point.


Shalom-Salam,

   Werner