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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 21:56, Chris Murphy wrote:
>
> Performance:
>
> dd if=/dev/zero ~56MB/s CPU < 10% dd if=/dev/urandom
> ~12MB/s
> CPU 99% haveged ~54MB/s CPU < 25%
>
>
> The dd relative values are
On Monday, March 26, 2012 03:56:43 PM Chris Murphy wrote:
> Performance:
>
> dd if=/dev/zero ~56MB/s CPU < 10%
> dd if=/dev/urandom~12MB/s CPU 99%
> haveged ~54MB/s CPU < 25%
>
>
> The dd relative values are consistent with kernels
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
On 03/26/2012 08:56 PM, Chris Murphy wrote:
>
> Performance:
>
> dd if=/dev/zero ~56MB/s CPU < 10%
> dd if=/dev/urandom~12MB/s CPU 99%
> haveged ~54MB/s CPU < 25%
>
>
> The dd relative values are consistent with kernels in Fedora 1
13 matches
Mail list logo
