View Single Post
Old 15th February 2014
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Quote:
Originally Posted by Alphalutra1 View Post
So I tweaked your tee stuff in a way I think allows you to measure how much strings pulls at a time:

Code:
< /dev/urandom strings -n1 | tee file.tmp | tr -dc _A-Z-a-z-0-9 | dd count=1 bs=16 2>/dev/null;echo
which gave a file.tmp size on OpenBSD of 80K; using tee before strings got one on my box of 184K. Similarly on Linux it gave me ~30K while starting with tee gave me ~65K. So strings seems to take smaller chunks than tee I guess?
Good idea, so I took it one step further and let tee also be in the 3rd position after the tr command. On Linux these are the file sizes:

Code:
49152  file-1
20480  file-2
 4096  file-3
Basically similar to what you observed, but it gets smaller still in the 3rd position. I'm not sure we can conclude one program is reading in bigger chunks than the other. It might just indicate how much data has been passed down the chain by the time everything terminates. That's a bit vague because I don't know exactly how that works.

I also don't know if tee is getting a chance to write out everything that passed through it or not. On one of my failed ideas (before hitting on tee) I wrote a simple C program that is like cat but counts how much data passes through it and writes the total to a file at the very end. When I put it in the pipeline, it never wrote the file. This suggests the pipe's programs may be terminated before they're "done" in the usual sense; they probably just get killed off, in turn, as soon as the final one finishes. If that happens to tee, it may be showing less than the actual amount read.

In any event this suggests strongly that lots of data is being read from /dev/urandom by this method, even if it's hard to tell exactly how much.

Quote:
Anyways, I'm now just taking 500 out of /dev/random which gives me a final file that's ~100 characters on linux, plenty of wiggle room and 500 isn't that bad a pull:

Code:
dd if=/dev/urandom count=1 bs=500 2>/dev/null | strings -n1 | tee file.tmp | tr -dc _A-Z-a-z-0-9 | tee file.tmpp | dd count=1 bs=16 2>/dev/null;echo
500 is much better but it still seems like more than needed. On Linux you can see the entropy pool size in bits with:

$ cat /proc/sys/kernel/random/entropy_avail

(See random(4).) This shows at most 4096 bits = 512 bytes. So reading 500 will nearly drain it, temporarily. For comparison, in a simple modification of my script you only need to read one byte out of /dev/urandom for every character in the password, with a uniformly distributed 64-character set. (The same size as your [:alnum:]_- set by coincidence!)

Note: I edited the above to correct the filename from "poolsize" to "entropy_avail" ... oops.

Last edited by IdOp; 15th February 2014 at 11:49 PM.
Reply With Quote