Is it ok to reuse the client session but just not closing it?
I send a SSL_write then a SSL_read command,
then I wait 30 seconds and send anther SSL_write
and another SSL_Read request. Is this an appropriate
way to reuse a connection?
Is it ok to reuse the client session but just not closing it?
I send a SSL_write then a SSL_read command,
then I wait 30 seconds and send anther SSL_write
and another SSL_Read request. Is this an appropriate
way to reuse a connection?
Hello,
I'm interested in having 'openssl' version 1.0.1e
make use, by default, of hardware generated
true random numbers for creating session keys.
So far I've configured a STElectronics ST33
TPM as the majority source of /dev/random
entropy by configuring and starting the
'rngd' daemon from
On Sat, Sep 21, 2013 at 2:09 PM, David Lawless
david_lawl...@flumedata.com wrote:
...
Next I did this:
cd /dev
mv urandom urandom.hold
mknod urandom c 1 8
Which causes /dev/urandom to make use of
the /dev/random driver in the kernel.
The above sort-of works. Some of the new
Not interested in BSD or Yarrow PRNG.
Not interested in any PRNG.
Interested in True RNG from hardware
as mixed by Theodore Ts'o excellent,
predominant and continually evolving
(https://lkml.org/lkml/2013/9/13/624)
/dev/random. Have more than enough
TRNG for the needs of the servers in
question.
On Sun, Sep 22, 2013 at 10:00 AM, starlight.201...@binnacle.cx wrote:
Not interested in any PRNG.
/dev/random is a PRNG. As I pointed out, True RBGs don't produce
enough material. The problem is the fact that /dev/random blocks.
No /dev/urandom is a PRNG. /dev/random
is a TRNG. Read the code
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=272b98c6455f00884f0350f775c5342358ebb73f
The TPM here generates 40Kbits/sec, or
5000 bytes/sec--more than enough for the
situation at
