Mailing List Archive

On Sun, 15 Jan 2006 13:45:13 +0100, Jean-Philippe Garcia Ballester said:

> We're checking if libgcrypt has already been initialized, so that we don't
> initialize it again in the library. But what if it has already been
> initalized without secure memory?

You mean by explictly disabling secure memory? Thn there is no way to
change this later (due to the mlock restrictions when using Linux)

> Is there something in gcry_control to check that, and the amount of secure
> memory (the documentation to gcry_control is either hard to find or
> inexistant)? Is there a solution to this problem other than saying

No. There is only the GCRYCTL_DUMP_SECMEM_STATS but this does not
help you program. Adding such a feature isn't hard and if you really
need it, we can do so.

Due to the problems with the secure memory I am currently thinking
about an option to get rid of mlocked secure memory but keeping the
automatic overwriting of that memory with a free. In case you have an
encrypted swap.


Shalom-Salam,

Werner



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sunday 15 January 2006 17:41, Werner Koch wrote:
> On Sun, 15 Jan 2006 13:45:13 +0100, Jean-Philippe Garcia Ballester said:
> > We're checking if libgcrypt has already been initialized, so that we
> > don't initialize it again in the library. But what if it has already been
> > initalized without secure memory?
>
> You mean by explictly disabling secure memory? Thn there is no way to
> change this later (due to the mlock restrictions when using Linux)

I mean in the program, there is just a call to :
gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0);

In the library used by the program, there is
if (!gcry_control(GCRYCTL_INITIALIZATION_FINISHED_P,0)){
gcry_control(GCRYCTL_INIT_SECMEM,524288,0);
gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0);
}

The gcry_control(GCRYCTL_INIT_SECMEM,524288,0) will not be done since
libgcrypt has already been initialized.

>
> > Is there something in gcry_control to check that, and the amount of
> > secure memory (the documentation to gcry_control is either hard to find
> > or inexistant)? Is there a solution to this problem other than saying
>
> No. There is only the GCRYCTL_DUMP_SECMEM_STATS but this does not
> help you program. Adding such a feature isn't hard and if you really
> need it, we can do so.

Not that it's really needed, but if some user initalize libgcrypt without
initalizing secure memory, that would end up in bugs coming from our lib.
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
initialize libgcrypt in their programs like our library should do.

--
Jean-Philippe Garcia Ballester

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.

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


Shalom-Salam,

Werner



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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

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



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel