[ale] little math

[Jim Kinney]

On Thu, Feb 11, 2010 at 11:28 AM, JK <jknapka at kneuro.net> wrote:

> On 2/11/2010 9:05 AM, Jim Kinney wrote:
> > Use the existing chunk of random data as a source. Now write a random
> > length of that source with some math done on it using another random
> > length. Mix in some random inversions and reversals and some overwrites
> > of the existing data and continue untill the drive is full.
>
>
> So... what you're really suggesting is, effectively, reading from a
> pseudo-random source rather than a genuinely random one.  Which seems
> totally reasonable in this context, although 1TB of pseudo-random
> data is a nice big sample for an attacker to analyze.  If the pattern
> of block allocations on the encrypted FS was also fairly unpredictable,
> though, the pseudo-random cyclic behavior might be effectively masked
> by the embedded genuine randomness of chunks of actual encrypted FS
> data.
>
> Doesn't Linux provide a character device for pseudo-random data?
>

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.

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.

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.

I'm sure there are many ways of generating large quantities of randomness
from a small quantity.

random.org publishes mebibit random data files. some mix and match will make
them useful.

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...

>
> -- JK
>
> --
> We Americans are a freedom-loving people, and nothing says "freedom"
> like Getting Away With It. -- Guy Forsyth, "Long Long Time"
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



-- 
-- 
James P. Kinney III
Actively in pursuit of Life, Liberty and Happiness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100211/f14728ed/attachment.html