On Apr 1, 2012, at 4:41 AM, Glen Turner wrote:
> Keeping a large sample on permanent storage of
> "random numbers" generated by that very machine is providing a very
> large lever to push against any flaw.
So you're suggesting it's better to /dev/zero the disk than /dev/urandom the
disk?
What a
The risk is reading unused blocks using the drive's hardware. Those
unused blocks may contain user data, operating system state, or a covert
channel allowing data or state to be inferred.
The response is to overwrite all of the disk with some value.
The random number generator is a higher risk me
On Fri, Mar 30, 2012 at 06:06:02PM -0400, Paul Wouters wrote:
> It's sad that even old cheap VIA CPUs have such a strong random device,
> that's fully supported with Linux, but that Intel and AMD still haven't
> caught up yet. My 3 week old intel cpu still seems to be lacking support
> for anything
On Fri, 30 Mar 2012, Steve Grubb wrote:
Something else I'd like to mention is that during system installation there is
very little system entropy. There is no saved seed to prime the generators with.
(LiveCD's have the same problem.) I have a feeling that the randomness of the
numbers is not wha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/03/12 21:01, Przemek Klosowski wrote:
> On 03/30/2012 01:02 PM, David Sommerseth wrote:
>>
>> That sounds reasonable. Unless I mix /dev/random and
>> /dev/urandom, the latter blocks until it has filled up the
>> entropy pool again.
>>
> Eh, th
On 03/30/2012 01:02 PM, David Sommerseth wrote:
That sounds reasonable. Unless I mix /dev/random and /dev/urandom,
the latter blocks until it has filled up the entropy pool again.
Eh, the FORMER (/dev/random) blocks until it has filled up the entropy
pool again. I seem to remember that urando
up the entropy pool again.
> What is the quality of pseudo-random data produced by urandom vs
> haveged?
PolarSSL used havege in v1.0 and below. It used RDTSC as a source for
seeding the randomisation. However, it turned out that in some
virtualised environment, the RDTSC values was quit
before letting it out.
> What is the quality of pseudo-random data produced by urandom vs haveged?
The quality of urandom is very good. Its studied every couple years for common
criteria purposes. Haveged on the other is never used in common criteria and
its
properties are largely unkn
On 03/26/2012 11:55 PM, Chris Murphy wrote:
>
>
> On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote:
>>
>> Well if you're just writing huge amounts of "random" data
>> to clear existing space, then you don't need it to be cryptographically
>> secure.
>> Why are you doing this exactly? Would /dev/
On 03/27/2012 05:23 AM, Gregory Maxwell wrote:
> On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy wrote:
>> So then the question is, if urandom is what's recommended, are faster
>> substitutes just as good? If they are just as good, then why aren't they the
>> first recommendation? And if this step
On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy wrote:
> So then the question is, if urandom is what's recommended, are faster
> substitutes just as good? If they are just as good, then why aren't they the
> first recommendation? And if this step is superfluous, then I'd suggest
> documentation b
On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote:
>
> Well if you're just writing huge amounts of "random" data
> to clear existing space, then you don't need it to be cryptographically
> secure.
> Why are you doing this exactly? Would /dev/zero suffice?
In every supposed best practice case of
consistent with kernels in Fedora 16. However
> these tests were done with 3.3.0-1. The questions are:
>
> Is the urandom performance expected?
>
> What is the quality of pseudo-random data produced by urandom vs haveged?
>
> If the qualities are similar, or haveged's
e:
Is the urandom performance expected?
What is the quality of pseudo-random data produced by urandom vs haveged?
If the qualities are similar, or haveged's is better, is there anything that
can be done to improve urandom's performance? It really takes quite a bit
longer to prepare a
14 matches
Mail list logo
