[gnutls-dev] Re: Memory leeks?

[Werner Koch]

On Fri, 27 Aug 2004 23:56:33 +0200, Simon Josefsson said:

> It seems like it would make sense to provide a new randomness mode.
> The new mode would work similar to what LSH do: read a seed file, and
> use a PRNG to generate more random data as needed.  This approach
> would be useful on embedded platforms, but also on platforms with
> closed source and/or otherwise dubious /dev/*random devices.

This is also current possible, you merely need to change the name of
/dev/random to /dev/null in configure ;-).  The design uses a PRNG
anyway.

However I doubt that this is something one should suggest except in
very rare cases.

> How to generate randomness should probably be orthogonal to the crypto
> back end used as well.  So here's the plan:

I don't think so.  A RNG is a basic building from cryptographic and
actually the hardest thing to do.  Not providing an easy API for this
will for sure lead to improper use of the other building blocks.  We
have seen in the past forgotten RNG intialization in many applications
and thus Libgcrypt tries its best to provide random by default.

What properties you need from your RNG depends highly on the
application and is something the protocol designers have to decide -
not the application implementor.

Anyway, DSA and Elgamal algorithms require random numbers anyway and
thus access to an RNG needs to be available inside the library.

> Btw, is it possible to build vanilla Libgcrypt on ColdFire?  I get MPI
> assembler failures.  I recall that the ColdFire architecture wasn't
> completely m68k compatible, but the errors look too basic to be

I am not sure; I have ported GnupG to Coldfire and givfen that the
code is basically the same it should not be really hard to do.  You
may want to look at scripts/autogen.sh from gnupg 1.2.

> jas at latte:~/src/libgcrypt$ m68k-uclinux-gcc --version
> m68k-uclinux-gcc (GCC) 3.4.0

I used gcc 2.95.3 with a couple of patches.  


  Werner