hu nice to know, thanks David! i will check this file
2013/9/25 David Johnston
> On 9/25/2013 2:19 PM, Roberto Spadim wrote:
> >
> >hi david!
> >do you have a patch about this hack?
>
> Actually Fedora 18 fixes the primary problems. It has an update to rngd so
> that it uses RdRand and it g
On 9/25/2013 2:19 PM, Roberto Spadim wrote:
>
>hi david!
>do you have a patch about this hack?
Actually Fedora 18 fixes the primary problems. It has an update to rngd
so that it uses RdRand and it gets invoked properly. I passed
information on to RedHat about the problems and they fixed it in F
hi david!
do you have a patch about this hack?
2013/9/25 David Johnston
> On 9/24/2013 11:58 AM, Roberto Spadim wrote:
>
>> There's space to create a new random device at /dev if you want too =)
>> /dev/nbrandom ? no block random? :)
>>
>> 2013/9/24 Richard Könning
>>
>> >:
>>
>>> Am 24.09.20
On 9/24/2013 11:58 AM, Roberto Spadim wrote:
There's space to create a new random device at /dev if you want too =)
/dev/nbrandom ? no block random? :)
2013/9/24 Richard Könning :
Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx:
At 12:59 9/23/2013 -0700, Michael Sierchio wrote:
I'
There's space to create a new random device at /dev if you want too =)
/dev/nbrandom ? no block random? :)
2013/9/24 Richard Könning :
> Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx:
>
>> At 12:59 9/23/2013 -0700, Michael Sierchio wrote:
>>>
>>>
>>> I'll repeat myself - the fact that
Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx:
At 12:59 9/23/2013 -0700, Michael Sierchio wrote:
I'll repeat myself - the fact that the
/dev/random implementation you're using
blocks is a serious design flaw.
Convince Linus, the GPG developers et al.--not me.
No one has to convi
Am 23.09.2013 21:59, schrieb starlight.201...@binnacle.cx:
At 20:27 9/23/2013 +0200, Richard Könning wrote:
/dev/random is a PRNG which blocks when the (crude)
entropy estimation of the entropy pool falls below a
limit. Besides this there are afaik no big
differences between /dev/random and /d
At 12:59 9/23/2013 -0700, Michael Sierchio wrote:
>
>I'll repeat myself - the fact that the
>/dev/random implementation you're using
>blocks is a serious design flaw.
Convince Linus, the GPG developers et al.--not me.
Till then I respect their view as embodied
by the latest implementation of rand
On Mon, Sep 23, 2013 at 12:59 PM, wrote:
> At 20:27 9/23/2013 +0200, Richard Könning wrote:
>>/dev/random is a PRNG which blocks when the (crude)
>>entropy estimation of the entropy pool falls below a
>>limit. Besides this there are afaik no big
>>differences between /dev/random and /dev/urando
At 20:27 9/23/2013 +0200, Richard Könning wrote:
>/dev/random is a PRNG which blocks when the (crude)
>entropy estimation of the entropy pool falls below a
>limit. Besides this there are afaik no big
>differences between /dev/random and /dev/urandom.
In the sense that all TRNG outputs are run
th
Am 22.09.2013 19:27, schrieb starlight.201...@binnacle.cx:
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
/dev/random is a PRNG which 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 han
On Sun, Sep 22, 2013 at 10:00 AM, 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.
__
OpenSSL Project
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 Sat, Sep 21, 2013 at 2:09 PM, David Lawless
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
> 'openssl' connect
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 'rng
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 'rng
17 matches
Mail list logo