Message-ID: <Pine.LNX.4.58.0310092140321.7809@nimue.bos.bindview.com>
Date: Thu, 9 Oct 2003 22:05:07 +0200 (CEST)
From: Michal Zalewski <lcamtuf@...ttot.org>
To: Dave Clendenan <dave@...e.clendenan.ca>
Cc: full-disclosure@...sys.com, bugtraq@...urityfocus.com
Subject: Re: [PAPER] Juggling with packets: floating data
 storage


On Thu, 9 Oct 2003, Dave Clendenan wrote:

> that way if the machine gets stolen they don't have the keyfile.

There are two problems with this and other suggestions (which is not to
say our proposal is flawless - it's simply sufficiently different to
deserve, at the very least, starting a discussion like this). First of
all, your method does nothing to maintain even a marginal level of
deniability, something you could do with the approach we have suggested.

Similarly, burying a DVD in the forest does nothing to make recovery
impossible, and I would argue it's actually less practical, except if you
do not plan to access the data until the threat of getting into trouble
because of it is long gone, AND if you produce the DVD and bury it long
before you have a reason to believe you are being followed by your foes
;-)

Admittably, if your traffic is sniffed for an extended period of time, the
deniability might be gone with our approach, too, but they would have to
first know what to look at, and even then, you can combine the approach
with steganography or deploy it over encrypted connections (https) and
store the data on a site you would otherwise visit this way (say, your
on-line bank or amazon.com). It will probably give you better results than
storing 100 bytes per porn JPG image in your collection (and is perhaps
more difficult to detect and leaves fewer traces on the non-volatile
media).

Then, in your approach, the data is still there, encrypted. You can be
forced to disclose the key, and if you don't (or have destroyed it), this
will be clearly against you. The approach does nothing to ensure the data
will be wiped. If you have generated the key using standard OS RNG, it
might turn out that the entropy gathering code was broken, or that MD5 or
SHA1 are susceptible to cryptoanalysis after all (neither reduces to a
classic "hard" problem in mathematics, right?).

And even if not, in a year, two, ten - well, one day - we are likely to
make some advances when it comes to finding factors for large numbers (as
Gates would put it, "prime numbers"), and then, your stuff is likely to be
exposed.

This does not have to happen, but very well may. And if you are out of
luck, it will happen before the authorities / evil cabal have decided to
give up on you.

So, to wrap up, the proposed approach has two advantages:

  - Assured destruction. If you go off-line or simply stop sending
    keep-alives, the data will be dropped and overwritten hundreds of
    times before anyone would realize it could be there.

  - Reasonable deniability while maintaining decent storage capacities
    can be achieved by not leaving traces on the machine in question
    and deploying some other clever tricks,

With proper redundancy, is actually fairly reliable, although is by no
means meant to mimick non-volatile storage.

Storage capacity is not as exciting, although it might be useful.
Arguments like "well, I can buy XX GB of RAM for $nnnn" are flawed - yes,
you can, and then you still can store some extra on the network.

I think the thread long deserves to die, though - we're essentially
reiterating two opposite views: some people do see some potential for this
approach, others don't.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-10-09 21:40 --

   http://lcamtuf.coredump.cx/photo/current/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists