[ale] little math

[JK]

On 2/12/2010 1:33 PM, Jim Popovitch wrote:
> On Fri, Feb 12, 2010 at 15:06, Brian Pitts<brian at polibyte.com>  wrote:
>> On 02/12/2010 01:58 PM, Jim Popovitch wrote:
>>> On Fri, Feb 12, 2010 at 11:37, JK<jknapka at kneuro.net>  wrote:
>>>> It's a lot easier to mount an attack on an encrypted data store if you
>>>> can identify which data is important.  The idea is to force the attacker
>>>> to analyze the entire 1TB drive, rather than being able to concentrate
>>>> on the 2GB of actual encrypted data.  This is also why really secure data
>>>> links transmit random data continuously -- an attacker has no idea which
>>>> data is real and which is just noise, so they have to waste a lot of
>>>> energy analyzing random junk and hope to get lucky.
>>>
>>>
>>> JK, You might be on to something there... how about an ALE
>>> presentation on the flaws and errors in present day Linux
>>> whole-disk-encryption because the disk is not constantly writing
>>> spurious data across the whole spectrum of sectors?
>>
>> Huh?
>
> You missed the sarcasm.
>
>> Writing random data to the entire disk before using it as an encrypted
>> data store should [0] be equivalent to a network link transmitting
>> random data continuously. The point is that if an attacker steals your
>> disk (or sniffs your network connection) and examines the blocks (or
>> packets) they can't tell what is meaningful data and what is noise.
>
> Right.  The previous analogy of transmitting random data continuously
> over data links does not apply here.


Wow, you seem to have seriously mis-interpreted my words. Sorry about
that.  All I was saying is that the goal is to hide genuine encrypted
data in an ocean of random data, so as to make an attack more difficult.
Obviously any repetition in the fake data is going to be a problem,
right?  Since it makes the location of the non-fake data obvious?

-- JK


-- 
We Americans are a freedom-loving people, and nothing says "freedom"
like Getting Away With It. -- Guy Forsyth, "Long Long Time"