<br><br><div class="gmail_quote">On Thu, Feb 11, 2010 at 11:28 AM, JK <span dir="ltr"><<a href="mailto:jknapka@kneuro.net">jknapka@kneuro.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 2/11/2010 9:05 AM, Jim Kinney wrote:<br>
> Use the existing chunk of random data as a source. Now write a random<br>
> length of that source with some math done on it using another random<br>
> length. Mix in some random inversions and reversals and some overwrites<br>
> of the existing data and continue untill the drive is full.<br>
<br>
<br>
</div>So... what you're really suggesting is, effectively, reading from a<br>
pseudo-random source rather than a genuinely random one. Which seems<br>
totally reasonable in this context, although 1TB of pseudo-random<br>
data is a nice big sample for an attacker to analyze. If the pattern<br>
of block allocations on the encrypted FS was also fairly unpredictable,<br>
though, the pseudo-random cyclic behavior might be effectively masked<br>
by the embedded genuine randomness of chunks of actual encrypted FS<br>
data.<br>
<br>
Doesn't Linux provide a character device for pseudo-random data?<br></blockquote><div><br>yep: /dev/urandom. It's a non-blocking psuedo-random generator. It recycles the entropy pool where as /dev/random will block until it gets more entropy.<br>
<br>The random processes on random data is effectively a random output. For absolutely random output, it is required to have 50% real random source data and the rest can be generated as random processes based on the source. A sequence of sums of random length number of a random source will be random. The tricky part in the algorithm is tracking the data source usage to not reuse it for the same type of operation twice. So it's OK to add block 123 and subtract block 123 but not to add block 123 twice.<br>
<br>All that said: another idea (I haven't done any calculations to see if this is actually valid) is to use a pair of sliding variable sized frames to extract blocks from the random source. One goes forward the other backwards so each reads out the string in the order viewed. That data set pair is concatenated and hashed to generate a new output for writing. One could easily choose a random start point for each frame and adjust the size randomly as well. <br>
<br>I'm sure there are many ways of generating large quantities of randomness from a small quantity.<br><br><a href="http://random.org">random.org</a> publishes mebibit random data files. some mix and match will make them useful.<br>
<br>Hmm. A bit of digging turned up lavarnd (an opensource offshoot of the now defunct lavarand from SGI). I recall I have a few really crappy webcams lying around...<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
-- JK<br>
<br>
--<br>
We Americans are a freedom-loving people, and nothing says "freedom"<br>
like Getting Away With It. -- Guy Forsyth, "Long Long Time"<br>
_______________________________________________<br>
</div><div class="im">Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
</div><div><div></div><div class="h5"><a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br>Actively in pursuit of Life, Liberty and Happiness <br><br>