full-disclosure - Re: [PAPER] Juggling with packets: floating data storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0310082011290.7809@nimue.bos.bindview.com>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Re: [PAPER] Juggling with packets: floating data storage

On Wed, 8 Oct 2003, Nicholas Weaver wrote:

> There is a hypothetical Gb optical network link between here and the
> moon, used for storage. Thus you could store a whopping 2 Gb of data, in
> a perfect network, or 256 MB.  My desktop at home has more DRAM, and has
> far better access behavior.  So the network layer juggling is pointless.

I think you have missed the point. Carrier media level juggling is
pointless, indeed, and we're not claiming otherwise; quite the opposite,
we consider it to be silly and we are not focusing on it. Network-level
juggling is much more interesting, because packet-processing latencies are
far higher; how much longer? There are some surprises.

> The higher level juggling is still pointless.  Lets assume I still have
> the 1 Gb link to the outside world, and the data round trip latency is a
> minute (the amount of time data can be stored externally before it comes
> back to me).  Thats still just 60 Gb of data, or 7.5 GB.  And I'm having
> to burn a 1 Gb link to do it!

Should you actually read the paper, it would be easier to comprehend the
idea. The paper proposes several approaches that do not require you to
send the data back and forth all the time; in some cases, you can achieve
near-infinite latency with a very low "sustaining traffic" necessary to
prevent the data from being discarded. Besides, the storage size is not
the main point, the entire approach is much more interesting from the
limited deniability high-privacy storage point of view.

> If my external link is "ONLY" 100 Mb, and the latency/refresh time is 1
> minute, thats 768 MB of data.

Your latency can be much higher, that's the first observation of the
paper, and it is possible without increasing access times in many cases.
Funny.

The second observation is that not all the data has to be send back and
forth all the time. Interesting.

The third observation is that there are some interesting applications of
this approach other than storing warez. Could there be?

So, while I hate to say this, reading the paper is usually a good idea
before ridiculing it...

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

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