[solved]/dev/random too fast?

nstgc · 2015-04-03 22:36:03

I'm a bit concerned that /dev/random isn't doing what it is suppose to be doing -- gathering pure entropy. My reasoning for this is that even in a live CD with no drives mounted (no drive activity) no typing, no mouse movement -- nothing, it can fill a file with "cat /dev/random > test.test" at a rate of 2.2 MB/s over a period of 61 seconds. I then tried this again, taking more time, just in case, but I ended up getting "buffer I/O error on dev dm-0, logical block #####, lost async page write", which apparently means that I ran out of space. https://bbs.archlinux.org/viewtopic.php … 5#p1509475

I also observed these speeds when I generated a 100MB file to use as a key file for a LUKS volume.

The reasons this is so shocking is that in the same time period, ~1 min, my laptop can only generate 67 B, and that's with me typing and moving the mouse around.

My hardware on my desktop is an i7-4930k, 5 HDD, an SSD, one CPU fan, and a graphics card.

Again, my concern is that /dev/random isn't doing it's job.

[edit=solution] haveged is running in both the livecd as well as on my installation. According to the Wiki haveged is a last resort and so I'll be looking to find another method of filling my entropy pool.

Last edited by nstgc (2015-04-04 15:33:48)

owain · 2015-04-03 22:48:20

/dev/random does its job, which is to create a random stream from the random and randomised information available, until the supply of random information runs out. It doesn't "gather pure entropy", whatever that is supposed to mean.

nstgc · 2015-04-03 22:56:16

Right, I know that, however the process of entropy is suppose to be slow.

By pure entropy, I mean without the use of some sort of hash or other trick (like with urandom).

By the way, on an actually install I'm getting 2.9 MB/s for random over 90s and 14.7 MB/s for urandom.

I don't doubt the program so much as where it is getting it's information. I'm concerned there is something in my system feeding it bad entropy.

amvakar · 2015-04-03 23:09:39

Per the Intel specification page (specifically the part about Data Protection Technologies) you have the hardware crypto acceleration including an RNG, which might explain the significant performance difference assuming your laptop doesn't have it.

nstgc · 2015-04-03 23:36:27

My desktop actually lacks the feature you are refering to, but my laptop has it. http://ark.intel.com/products/78930/Int … o-3_50-GHz

My Desktop has the AES instruction set, which is just that. This would help with cryptographic computations such as those used in urandom. My laptop, however, has both the instruction set and "Secure Key" which is the RNG.

Last edited by nstgc (2015-04-03 23:36:59)

circleface · 2015-04-04 00:03:48

Do you have a program like haveged running that might be generating entropy?

nstgc · 2015-04-04 13:36:54

No. That was part of the reason I wanted to try it in from a live disk, to make sure it was on some standardized systemed (March's by the way). Still, none of my systems, to my knowledge, have any sort of special psudorandom number generator.

frostschutz · 2015-04-04 13:59:54

Check 'top' while 'cat' is running. If there is a user space process that is generating entropy, it would show up alongside with the cat in the top cpu usage. On my system, haveged is around 40% CPU when I dump /dev/random to /dev/null.

nstgc · 2015-04-04 15:32:22

I see. Yes, haveged is running. Okay, that was kind of what I was afraid of. I'd rather use entropy gathered from my system. Thank you. I disabled haveged.service and ran the test again and /dev/random was filling at a more reasonable rate of 0 kB/s. I'll need to figure out something else since the haveged entry in the Wiki seems to suggest that haveged should be a last resort.

frostschutz · 2015-04-04 16:31:20

nstgc wrote:

I'd rather use entropy gathered from my system.

Well, haveged gathers it from your system.

And what haveged does is no less artificial than you hammering the any key while waiting for /dev/random to produce any data whatsoever.

Most people are happy with /dev/urandom anyhow. http://www.2uo.de/myths-about-urandom/

ewaller · 2015-04-04 17:24:47

frostschutz wrote:

Most people are happy with /dev/urandom anyhow. http://www.2uo.de/myths-about-urandom/

Not everyone.

Arch Linux

#1 2015-04-03 22:36:03

[solved]/dev/random too fast?

#2 2015-04-03 22:48:20

Re: [solved]/dev/random too fast?

#3 2015-04-03 22:56:16

Re: [solved]/dev/random too fast?

#4 2015-04-03 23:09:39

Re: [solved]/dev/random too fast?

#5 2015-04-03 23:36:27

Re: [solved]/dev/random too fast?

#6 2015-04-04 00:03:48

Re: [solved]/dev/random too fast?

#7 2015-04-04 13:36:54

Re: [solved]/dev/random too fast?

#8 2015-04-04 13:59:54

Re: [solved]/dev/random too fast?

#9 2015-04-04 15:32:22

Re: [solved]/dev/random too fast?

#10 2015-04-04 16:31:20

Re: [solved]/dev/random too fast?

#11 2015-04-04 17:24:47

Re: [solved]/dev/random too fast?

Board footer