gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnutls-dev] Re: Memory leeks?


From: Simon Josefsson
Subject: [gnutls-dev] Re: Memory leeks?
Date: Fri, 27 Aug 2004 23:56:33 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Werner Koch <address@hidden> writes:

> You should be more worried on how to get enough entropy for the RNG; I
> have once experimented with a Coldfire board and tehre is no clean
> solution except for installing a unique random_seed file and hope for
> the best.

This is a good point.  Currently, GnuTLS support randomness from
Libgcrypt, and (in 1.1, via --with-nettle) by reading /dev/*random.

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.

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

There should be --with-nettle to select between Libgcrypt/Nettle for
secret key ciphers, hashes etc, but _not_ randomness.

There should be --with-libgcrypt-random (the default),
--with-device-random (my new code that access /dev/*random directly),
and a third option --with-seeded-random that require a secret seed
file.

If ever GnuTLS drop the hard requirement on libgcrypt, then
--with-nettle naturally would have to enable --with-device-random to
avoid the libgcrypt dependency for randomness only.

Thoughts on this appreciated.  I guess the choice of PRNG can be
discussed.  Supporting Yarrow is simple, it is part of Nettle, but
perhaps people dislike it.  Preferably, it should be easy to replace
the PRNG used.

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
because of that.

make[2]: Entering directory `/home/jas/src/libgcrypt/mpi'
/bin/sh ../libtool --mode=compile m68k-uclinux-gcc  -g -O2 -c -o mpih-add1.lo 
`test -f 'mpih-add1.S' || echo './'`mpih-add1.S
 m68k-uclinux-gcc -g -O2 -c mpih-add1.S -o mpih-add1.o
mpih-add1.S: Assembler messages:
mpih-add1.S:51: Error: parse error -- statement `movel d2,address@hidden' 
ignored
mpih-add1.S:52: Error: parse error -- statement `movel a2,address@hidden' 
ignored
mpih-add1.S:55: Error: parse error -- statement `movel sp@(12),a2' ignored
mpih-add1.S:56: Error: parse error -- statement `movel sp@(16),a0' ignored
mpih-add1.S:57: Error: parse error -- statement `movel sp@(20),a1' ignored
mpih-add1.S:58: Error: parse error -- statement `movel sp@(24),d2' ignored
mpih-add1.S:61: Error: operands mismatch -- statement `lsrl #1,d2' ignored
mpih-add1.S:66: Error: parse error -- statement `movel address@hidden,d0' 
ignored
mpih-add1.S:67: Error: parse error -- statement `movel address@hidden,d1' 
ignored
mpih-add1.S:68: Error: operands mismatch -- statement `addxl d1,d0' ignored
mpih-add1.S:69: Error: parse error -- statement `movel d0,address@hidden' 
ignored
...
address@hidden:~/src/libgcrypt$ m68k-uclinux-gcc --version
m68k-uclinux-gcc (GCC) 3.4.0

Thanks,
Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]