Use of custom memory allocators

[Nikos Mavrogiannopoulos]

Werner Koch wrote:
> On Thu,  4 Dec 2008 20:37, simon at josefsson.org said:
> 
>> If I remove that code, using any application that uses the GnuTLS
>> library with some functions just dies:
>>
>> jas at mocca:~/src/gnutls/src master$ ./certtool -p
>> Generating a 2048 bit RSA private key...
>> Ohhhh jeeee: operation is not possible without initialized secure memory
> 
> Right, because it is not properly initialized.  We need to fix the
> application and not try to work around such problems.

I also disagree here :) Have a "secure" memory is only of use to limited
applications that conform to some different threat models than a typical
PC server is faced with. Those special ones know their requirements and
will set this behavior explicitly. For others there should be some
reasonable defaults.

Also if you disagree with my evaluation that common applications do not
require a secure memory, the same argument applies. A reasonable default
with secure memory initialized should be available.

>    If you don't have a need for secure memory, for example if your
> application does not use secret keys or other confidential data or it
> runs in a controlled environment where key material floating around in
> memory is not a problem, you - or weel the application - should
> initialize Libgcrypt correctly. 

As far as I know modern operating systems do not leave random memory
floating around and being shared between processes. Also memory is being
zeroed before being given to an application. Thus the threat-model for
having a special memory marked as "secure" is not quite clear for me and
this is the reason it was always by default off in gnutls.

> I am sorry that these things are a bit complicated.  However I believe
> that we should better choose the safe side of things.  The crypto
> library is low-level foundation code and problems there would affect a
> lot of applications.  Better some applications break than applications
> requiring real security are exploitable.

I agree choosing the safe side of things. However it should also be
clear what the threat-model of using secure memory will protect from.
The additional security offered by it might not worth the inconvenience
offered by it -limited secure memory that will cause the application to
fail in cases where it was exceeded.

regards,
Nikos