Discussion:
[PAPER] Juggling with packets: floating data storage
(too old to reply)
Wojciech Purczynski
2003-10-06 08:59:54 UTC
Permalink
The following paper explores the possibilities of using certain
properties of the Internet or any other large network to create
a reliable, volatile distributed data storage of a large capacity.

==============================================
Juggling with packets: floating data storage
==============================================

"Your dungeon is built on an incline. Angry monsters can't play
marbles!"

Wojciech Purczynski <***@isec.pl>
Michal Zalewski <***@coredump.cx>


1) Juggle with oranges!
------------------------

Most of us, the authors of this paper, have attempted to juggle with
three or more apples, oranges, or other fragile ballistic objects.
The effect is usually rather pathetic, but most adept juggler padawans
sooner or later learn to do it without inflicting excessive collateral
damage.

A particularly bright juggler trainee may notice that, as long as he
continues to follow a simple procedure, at least one of the objects is
in the air at all times, and that he has to hold at most two objects
in his hands at once. Yet, each and every apple goes thru his hands
every once in a while, and it is possible for him to recover it at
will.

He may then decide the entire process is extremely boring and go back
to his computer. And while checking his mail, an educated juggler may
notice that a typical network service has but one duty: to accept and
process data coming from a remote system, and take whatever steps it
deems appropriate based on its interpretation of the data. Many of
those services do their best to behave robustly and be fault-tolerant
- and, why not, to supply useful feedback about the transaction.

In some cases, the mere fact a service is attempting to process the
data and reply conforming to the protocol can be used in the ways
authors never dreamed of. One of more spectacular examples, which our
fellow juggler may be familiar with, is a research done at the
University of Notre Dame, titled "Parasitic Computing" and published
in letters to "Nature". The researchers have attempted to use TCP/IP
checksum generation algorithm to perform boolean operations necessary
to solve non-polynomial problems.

Nevertheless, such attempts were quite impractical in the real world,
concludes our hero; the cost of preparing and delivering a trivia to
be solved far exceeds any eventual gain - the sender has to perform
operations of comparable computational complexity to even deliver the
request. The computing power of such a device is puny! - we hear him
saying.

A real juggler would focus on a different kind of outsourced data
processing, one that is much closer to his domain of expertise. Why,
distributed parasitic data storage, of course. - What if I write
a single letter on every orange, and then start juggling? I can then
store more orange-bytes than my physical capacity (the number of
oranges I can hold in my hands) is! How brilliant... But, but, would
it work without oranges?


2) The same, without oranges
-----------------------------

The basic premise for this paper is the observation that for all
network communications, there is a non-zero (and often considerable)
delay between the act of sending an information and receiving a reply.
The effect should be contributed to the physical constrains of the
medium, and to the data processing times in all computer equipment.

A packet storing a piece of data, just like an orange with a message
written on it, once pushed travels for a period of time before coming
back to the source - and for this period of time, we can safely
forget its message without losing data.

As such, the Internet has a non-zero momentary data storage capacity.
It is possible to push out a piece of information and effectively have
it stored until echoed back. By establishing a mechanism for cyclic
transmission and reception of chunks of data to and from a number of
remote hosts, it is possible to maintain an arbitrary amount of data
constantly `on the wire', thus establishing a high-capacity volatile
medium.

The medium can be used for memory-expensive operations, as a regular
storage, or for handling certain types of sensitive data that are
expected not to leave a physical trail on a hard disk or other
non-volatile media.

Since it is not considered a bad programming practice to send back as
much relevant information as the sender had sent to the service, and
many services or stacks maintain a high level of verbosity, based on
our juggling experience, we conclude it is not only possible, but also
feasible to establish this kind of storage, even over a low-end
network hook-up.

As opposed to traditional methods of parasitic data storage (P2P
abuse, open FTP servers, binary Usenet postings), the use of this
medium may or may not leave a trail of data (depending on a solution
used) and specifically does not put any single system under
a noticable load. The likehood of this technique being detected,
considered an abuse, and the data being removed, is much lower.


3) Class A data storage: memory buffers
----------------------------------------

Class A data storage uses the capacity inherent to communication
delays during the transmission and processing of live data. The
information remains cached in the memory of a remote machine, and is
not likely to be swapped out to a disk device.

Examples rely on sending a message that is known to result in
partial or full echo of the original request, and include:

- SYN+ACK, RST+ACK responses to SYN packets and other bounces,

- ICMP echo replies,

- DNS lookup responses and cache data. It is possible to store some
information in a lookup request and have it bounced back with
a NXDomain reply; or to store data in NS cache,

- Cross-server chat network message relaying. Relaying text messages
across IRC servers and so on can exhibit considerable latency,

- HTTP, FTP, web proxy or SMTP error or status replies,

Most important properties of class A storage are:

- Low latency (miliseconds to minutes), making it more useful
for near random access memory applications,

- Lower per-system capacity (usually kilobytes), making it less
suitable for massive storage,

- Only one chance to receive, or few retransmits, making it
less reliable in case of a network failure,

- Data not likely to be stored on a non-volatile medium or swapped
out, increasing privacy and deniability.

In particular, when using higher level protocols, additional features
appear which may solve some of above disadvantages. It is possible to
establish a connection to a service such as SMTP, FTP, HTTP or any
other text-based service, and send a command that is known to result
in an acknowledgment or error message being echoed along with part of
the original data. We do not, however, send full formatted message,
leaving some necessary characters unsent. In most cases end-of-line
characters are required in order the command to be completed. In this
state, our data is already stored on remote service waiting for
a complete command or until connection timeout occurs.

To prevent timeouts, either on TCP or application level, no-op packets
need to be sent periodically. \0 character interpreted as an empty
string has no effect on many services but is sufficient to reset TCP
and service timeout timers. A prominent example of an application
vulnerable to this attack is Microsoft Exchange.

The attacker can sustain the connection for an arbitrary amount of
time, with a piece of data already stored at the other end. To recover
the information, the command must be completed with missing \r\n and
then response is send to the client.

A good example is SMTP VRFY command:

220 inet-imc-01.redmond.corp.microsoft.com Microsoft.com ESMTP Server
Thu, 2 Oct 2003 15:13:22 -0700
VRFY AAAA...
252 2.1.5 Cannot VRFY user, but will take message for
<***@microsoft.com>

It is possible to store just over 300 bytes, including non-printable
characters, this way - and have it available almost instantly.

More data may be stored if HTTP TRACE method is used with data passed
in arbitrary HTTP headers, depending on the server software.

Sustained connections may give us arbitrarily high latency, thus
making large storage capacity.

This type of storage is naturally more suited for privacy-critical
applications or low-latency lower to medium capacity storage
(immediate RAM-extending storage for information that should leave no
visible traces).

The storage is not suitable for critical data that should be preserved
at all costs, due to the risk of data being lost on network failure.


4) Class B data storage: disk queues
-------------------------------------

Class B data storage uses "idle" data queues that are used to store
information for an extended period of time (often on the disk).
Particularly on MTA systems mail messages are queued for up to 7 days
(or more, depending on the configuration). This feature may give us
a long delay between sending data to store on remote host and
receiving it back.

As a typical SMTP server prevents to relay mail from the client to
himself, mail bounces may be used to get data returned after long
period of time.

An example attack scenario:

1. The user builds a list of SMTP servers (perhaps ones that provide
a reasonable expectation of being beyond the reach of his foes),

2. The user blocks (with block/drop, not reject) all incoming
connections to his port 25.

3. For each server, the attacker has to confirm its delivery timeouts
and the IP from which the server connects back while trying to
return a bounce. This is done by sending an appropriate probe to
an address local to the server (or requesting a DSN notification
for a valid address) and checking how long the server tries to
connect back before giving up. The server does not have to be an
open relay.

4. After confirming targets, the attacker starts sending data at
a pace chosen so that the process is spread evenly over the
period of one week. The data should be divided so that there
is one chunk per each server. Every chunk is sent to a separate
server to immediately generate a bounce back to the sender.

5. The process of maintaining the data boils down to accepting
an incoming connection and receiving the return at most a week
from the initial submission, just before the entry is about
to be removed from the queue. This is done by allowing this
particular server to go thru the firewall. Immediately after
receiving a chunk, it is relayed back.

6. To access any portion of data, the attacker has to look up which
MTA is holding this specific block, then allow this IP to connect
and deliver the bounce. There are three possible scenarios:

- If the remote MTA supports ETRN command, the delivery can be
induced immediately,

- If the remote MTA was in the middle of a three-minute run in
attempt to connect to a local system (keeps retrying thanks to
the fact its SYN packets are dropped, not rejected with RST+ACK),
the connection can be established in a matter of seconds,

- Otherwise, it is necessary to wait between 5 minutes and
an hour, depending on queue settings.

This scheme can be enhanced using DNS names instead of IPs for users
on dynamic IP or to provide an additional protection (or when it is
necessary to cut the chain immediately).

Important properties of class B storage:

- High per-system capacity (megabytes), making it a perfect solution
for storing large files and so on,

- Higher access latency (minutes to hours), likening it to a tape
device, not RAM (with exceptions of SMTP hosts that accept ETRN
command to immediately re-attempt delivery),

- Very long lifetime, increasing per-user capacity and reliability,

- Plenty of delivery attempts, making it easy to recover the data
even after temporary network or hardware problems,

- Likely to leave a trace on the storage devices, making it a less
useful solution for fully deniable storage (although it would
still require examining a number of foreign systems, which does
not have to be feasible).

Class B storage is suitable for storing regular file archives,
large append-only buffers, encrypted resources (with a proper
selection of hosts, it remains practically deniable), etc.


5) Discreet class A storage
----------------------------

In certain situations, it might be necessary to advise a solution for
discreet data storage that is not stored on the machine itself, and
makes it possible to deny the presence of this information on any
other system.

The basic requirement is that the data is:

- not being delivered back until a special key sequence
is sent,

- permanently discarded without leaving any record on any
non-volatile storage media in absence of keep-alive
requests

It is possible to use class A storage to implement this functionality
using the sustained command method discussed above. The proper TCP
sequence number is necessary to release the data, and until this
sequence is delivered, the data is not sent back or disclosed to any
party. If the client node goes offline, the data is discarded and
likely overwritten.

The sequence number is thus the key to the stored information,
and, granted the lifetime of the data is fairly short when
keep-alive \0s stop coming, it is often an adequate protection.


6) User-accessible capacity
----------------------------

In this section, we attempt to estimate the capacity available to
a single user.

To maintain a constant amount of data "outsourced" to the network, it
is required to receive and send it back on a regular basis.

The time data may be stored remotely is defined by maximum lifetime
Tmax of a single packet (including packet queuing and processing
delays). The maximum amount of data that may be sent is limited by
maximum available network bandwith (L).

Thus, the maximum capacity can be defined as:

Cmax [bytes] = L [bytes/second] * Tmax [seconds] / Psize * Dsize

where:

Dsize - size of a packet required to store an initial portion of
data on remote host

Psize - size of a packet required to sustain the information
stored on remote host

Psize and Dsize are equal and thus can be omitted whenever the
entire chunk of data is bounced back and forth, and differ only
for "sustained command" scenarios. The smallest TCP/IP packet to
accomplish this would have 41 bytes. The maximum amount of data
that can be sustained using HTTP headers is about 4096 bytes.

That all, in turn, gives us the following chart:

Bandwith | Class A | Class B
-----------+---------+---------
28.8 kbps | 105 MB | 2 GB
256 kbps | 936 MB | 18 GB
2 Mbps | 7.3 GB | 147 GB
100 Mbps | 365 GB | 7 TB


7) Internet as a whole
-----------------------

In this section, we attempt to estimate the theoretical momentary
capacity of the Internet as a whole.

Class A:

To estimate theoretical class A storage capacity of the Internet,
we assumed that:

- ICMP messages are the best compromise between storage
capacity and preserving remote system's resources,

- An average operating system has a packet input queue capable
of holding at least 64 packets,

- The default path MTU is around 1500 (the most common MTU).

We have taken the estimated number of hosts on the Internet from ISC
survey for 2003, which listed a count of 171,638,297 systems with
reverse DNS entries. Not all IPs with reverse DNS have to be
operational. To take this into account, we have used ICMP echo
response ratio calculated from the last survey that performed such
a test (1999). The data suggested that approximately 20% of visible
systems were alive. This sets the number of systems ready to respond
ICMP requests at roughly 34,000,000.

By multiplying the number of systems that reply to ICMP echo request
by the average packet cache size and maximum packet size (minus
headers), we estimate the total theoretical momentary capability for
class A ICMP storage to be at approximately 3 TB.

Class B:

To estimate theoretical class B storage capacity, we use the example
of MTA software. There is no upper cap for the amount of data we
feed to a single host. While it is safe to assume only messages
under approximately one megabyte are not going to cause noticable
system load and other undesirable effects, we assume the average
maximum queue size to be at 500 MB.

Own research suggests that roughly 15% of systems that respond to
ping requests have port 25 open. We thus estimate the population of
SMTP servers to be 3% (15% of 20%) of the total host count, that is
just over 5,000,000 hosts.

This gives a total storage space capacity of 2500 TB.


8) Legal notice
----------------

The authors reserve right to a method and system for cheap data
storage for developing countries.

A do-it-yourself kit (long wire, speaker + microphone, shovel and
a driver disk) will provide an affordable, portable and reusable way
for extending storage memory on portable systems.

It is estiamted that, after digging a 100 ft well, it is possible to
achieve over six kilobits of extra RAM storage at 20 kHz.

We are currently looking for distributors.


9) Credits
-----------

The authors would like to thank Lance Spitzner for a brief review
of this paper and some useful suggestions and comments.


10) Availability

You may always find this paper under following locations:

http://isec.pl/papers/juggling_with_packets.txt
http://lcamtuf.coredump.cx/juggling_with_packets.txt
--
Wojciech Purczynski
iSEC Security Research
http://isec.pl/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
petard
2003-10-06 14:13:11 UTC
Permalink
Post by Wojciech Purczynski
The following paper explores the possibilities of using certain
properties of the Internet or any other large network to create
a reliable, volatile distributed data storage of a large capacity.
==============================================
Juggling with packets: floating data storage
==============================================
You stole this idea from Simon, didn't you? :-)

http://members.iinet.net.au/~bofh/newbofh/bofh2apr97.html

(See the original here... that is just a page with the single
posting on it: http://bofh.ntk.net/Bastard_1997-1.html)



--
If your message really might be confidential, download my PGP key here:
http://petard.freeshell.org/petard.asc
and encrypt it. Otherwise, save bandwidth and lose the disclaimer.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Alun Jones
2003-10-08 16:52:53 UTC
Permalink
-----Original Message-----
Sent: Monday, October 06, 2003 4:00 AM
A real juggler would focus on a different kind of outsourced data
processing, one that is much closer to his domain of expertise. Why,
distributed parasitic data storage, of course. - What if I write
a single letter on every orange, and then start juggling? I can then
store more orange-bytes than my physical capacity (the number of
oranges I can hold in my hands) is! How brilliant... But, but, would
it work without oranges?
Of course, a real network engineer would remind you that you face two
immediate problems regarding this technique:

1. [UDP] Jugglers don't usually have to deal with oranges suddenly
disappearing in midflight, or being duplicated.
2. [TCP] Jugglers don't have to hold onto a copy of their thrown orange
until such time as the catching hand lets them know that it's been caught.

Yes, networks can be used as storage, and in the very early days of
computing, "storage" was essentially a delay line with an amplifier -
whether this was an oscilloscope with an array of light sensors, or a coil
of wire, etc. This is roughly similar to the proposal under discussion.
Protecting network-borne data from corruption and loss is not a trivial
problem. Good luck.

Alun.
~~~~
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place | ***@texis.com.
Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.
Nicholas Weaver
2003-10-08 19:03:20 UTC
Permalink
Post by Alun Jones
Of course, a real network engineer would remind you that you face two
1. [UDP] Jugglers don't usually have to deal with oranges suddenly
disappearing in midflight, or being duplicated.
This can be handled, up to a point, by standard error-handling
techniques.

However, a little bit of back-of-the-envelope on an orthoginal access:
Measuring the latency (how long the object remains "in the network").


There is a hypothetical Gb optical network link between here and the
moon, used for storage.

The moon is ~3e8 m from Earth (384,000 km). Thus it is about 2
seconds of network latency from here to the moon.

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.

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!

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

So who cares? Why juggle when shelves hold so much more?
--
Nicholas C. Weaver ***@cs.berkeley.edu
Rick Wash
2003-10-08 19:46:22 UTC
Permalink
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
Just because you and I don't have a use for this doesn't make it useless.

This technique has one advantage that I can see being very useful -- it is
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly. Hard drives need to be overwritten many times, but even then
they can still likely be recovered with enough money put toward it.

Rick
David Heigl
2003-10-08 20:23:36 UTC
Permalink
You know, this topic is quickly getting out of hand, but I can't help but
wonder what you were doing spewing 6.5 gigabytes of incriminating data
around on a link with a minute of latency, just so you wouldn't have to
store it locally... Or perhaps you meant that you have a ~11 million mile
long reel of fiber in your basement?

Dave Heigl
erst-while troll and nay-sayer


----- Original Message -----
From: "Rick Wash" <***@citi.umich.edu>
To: "Nicholas Weaver" <***@CS.berkeley.edu>
Cc: "Alun Jones" <***@texis.com>; "'Wojciech Purczynski'" <***@isec.pl>;
"'Michal Zalewski'" <***@coredump.cx>; <***@securityfocus.com>;
<***@securityfocus.com>; <***@vulnwatch.org>;
<***@vulnwatch.org>; <full-***@netsys.com>
Sent: Wednesday, October 08, 2003 2:46 PM
Subject: Re: [PAPER] Juggling with packets: floating data storage
Post by Rick Wash
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
Just because you and I don't have a use for this doesn't make it useless.
This technique has one advantage that I can see being very useful -- it is
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly. Hard drives need to be overwritten many times, but even then
they can still likely be recovered with enough money put toward it.
Rick
Michal Zalewski
2003-10-08 20:28:26 UTC
Permalink
A ramdisk.
Quite expensive, though, not to mention the data or its parts are quite
likely to get swapped out at some point. Our calculations indicate that
you can store much more data than Nicholas suggested, although with some
caveats, so paying $40 for a DSL line may be a cheaper alternative to
buying gigabytes of RAM.

There is only a limited deniability, of course, as someone might have been
sniffing on you; thankfully, some of the methods we describe are actually
"send-once, deliver keep alives later on", so it might be easier to deny
the presence of any data.

The purpose of the paper was precisely to provoke a discussion on more
ambitious uses of this media, not to announce there is a new way to store
your 1 TB mp3 collection.

That said, I'd prefer to refrain from getting into a flame war and
defending the paper by all means - you are free to judge it and to
disagree; I would simply prefer if you could give it a chance.

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

http://lcamtuf.coredump.cx/photo/current/
Doug Moen
2003-10-08 20:10:40 UTC
Permalink
Post by Rick Wash
This technique has one advantage that I can see being very useful -- it is
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly.
A ramdisk.

Doug Moen.
Michal Zalewski
2003-10-08 20:45:05 UTC
Permalink
A ramdisk.
Quite expensive, though, not to mention the data or its parts are quite
likely to get swapped out at some point. Our calculations indicate that
you can store much more data than Nicholas suggested, although with some
caveats, so paying $40 for a DSL line may be a cheaper alternative to
buying gigabytes of RAM.

There is only a limited deniability, of course, as someone might have been
sniffing on you; thankfully, some of the methods we describe are actually
"send-once, deliver keep alives later on", so it might be easier to deny
the presence of any data.

The purpose of the paper was precisely to provoke a discussion on more
ambitious uses of this media, not to announce there is a new way to store
your 1 TB mp3 collection.

That said, I'd prefer to refrain from getting into a flame war and
defending the paper by all means - you are free to judge it and to
disagree; I would simply prefer if you could give it a chance.

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

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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Doug Moen
2003-10-08 21:25:05 UTC
Permalink
Post by Rick Wash
This technique has one advantage that I can see being very useful -- it is
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly.
A ramdisk.

Doug Moen.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
MightyE
2003-10-08 20:44:25 UTC
Permalink
Post by Rick Wash
Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly.
RAM?

I haven't priced gigabit hardware recently, but I imagine it's similar
or more expensive to maintain a gigabit fiber long enough to hold 6.5 GB
of data as it is to create a 6.5 GB ramdisk.

The use here (if you must find one) is in hiding data where others don't
expect it.

-Eric Stevens
mightye at mightye dot org
Post by Rick Wash
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
Just because you and I don't have a use for this doesn't make it useless.
This technique has one advantage that I can see being very useful -- it is
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly. Hard drives need to be overwritten many times, but even then
they can still likely be recovered with enough money put toward it.
Rick
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Seth Breidbart
2003-10-08 20:54:12 UTC
Permalink
Post by Rick Wash
This technique has one advantage that I can see being very useful --
it is easy to delete large amounts of data quickly. Imagine you
hear the feds knocking on your door -- you just unplug your fiber,
and let all the light (aka your data) fly out into the room. Your
data is gone, permanently. If the latency is a minute, then it only
takes a minute to delete everything -- all 6.5 GB of data according
to your calculations. Show me another method that can delete 6.5 GB
a data in a completely unrecoverable manner that quickly.
Thermite. However, it's obvious that you did it. I can't think of
any other fast method that doesn't leave blatant physical evidence.

Seth

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Aron Nimzovitch
2003-10-08 22:31:02 UTC
Permalink
Date: Wed, 8 Oct 2003 15:46:22 -0400
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly.


To continue, that works a few times, then the "doorknockers" realize
that everything they are after is freely available, thanks to you.
Fiber is dirt simple to tap. Plus the access latency in this approach
handicaps it for anything useful (see magnetic bubble memories). Oh,
and the alternate method is easy, no hard storage, i.e. everything in
RAM with a marginal power supply. Delay line storage has been around
for a long time, if it was useful, it would be commerical.
b***@umtstrial.co.uk
2003-10-09 15:30:08 UTC
Permalink
Show me another method that can delete 6.5 GB a data in a completely
unrecoverable manner that quickly.
Store your data on a crypto-loopback partition, but that requires a
passphrase, _and_ a key file containing random data to access it.

In the event of an "emergency", simply shred -uvz /path/to/keyfile, and
reboot.
Your data will be rendered completely useless.

I started playing with this, and wrote a simple shellscript to help out with
this.

http://gk.umtstrial.co.uk/~calum/mountscript/


Calum

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Michal Zalewski
2003-10-09 20:05:07 UTC
Permalink
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
Dave Clendenan
2003-10-09 19:24:50 UTC
Permalink
Post by b***@umtstrial.co.uk
Show me another method that can delete 6.5 GB a data in a completely
unrecoverable manner that quickly.
Store your data on a crypto-loopback partition, but that requires a
passphrase, _and_ a key file containing random data to access it.
In the event of an "emergency", simply shred -uvz /path/to/keyfile, and
reboot.
Your data will be rendered completely useless.
better yet, if you generally have physical access to the machine, keep
a keyfile on a usb keychain. I mount /home this way with on my
(slackware) laptop, with loop AES.
http://sourceforge.net/projects/loop-aes/

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

--
Dave Clendenan
***@clendenan.ca

PGP fingerprint: 910E 8400 7A16 822C 9B62 209F 6CAB DEDF BF4B DF75

Subtlety is the art of saying what you think,
and getting out of the way before it is understood

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
V***@vt.edu
2003-10-09 19:08:49 UTC
Permalink
Post by b***@umtstrial.co.uk
Store your data on a crypto-loopback partition, but that requires a
passphrase, _and_ a key file containing random data to access it.
In the event of an "emergency", simply shred -uvz /path/to/keyfile, and
reboot.
Your data will be rendered completely useless.
And if you did a 'mount -t netloop /path/to/keyfile', there's not even a need to
shred the file. :)
Thomas Chiverton
2003-10-09 15:04:39 UTC
Permalink
Post by Aron Nimzovitch
RAM with a marginal power supply. Delay line storage has been around
for a long time, if it was useful, it would be commerical.
Delay line storage is typicaly very expensive (mercury is HazMat !) though,
where as this is very cheap indeed.
--
Tom Chiverton
Advanced ColdFusion Programmer

Tel: +44(0)1749 834997
email: ***@bluefinger.com
BlueFinger Limited
Underwood Business Park
Wookey Hole Road, WELLS. BA5 1AF
Tel: +44 (0)1749 834900
Fax: +44 (0)1749 834901
web: www.bluefinger.com
Company Reg No: 4209395 Registered Office: 2 Temple Back East, Temple
Quay, BRISTOL. BS1 6EG.
*** This E-mail contains confidential information for the addressee
only. If you are not the intended recipient, please notify us
immediately. You should not use, disclose, distribute or copy this
communication if received in error. No binding contract will result from
this e-mail until such time as a written document is signed on behalf of
the company. BlueFinger Limited cannot accept responsibility for the
completeness or accuracy of this message as it has been transmitted over
public networks.***

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
V***@vt.edu
2003-10-09 15:54:18 UTC
Permalink
Post by Aron Nimzovitch
RAM with a marginal power supply. Delay line storage has been around
for a long time, if it was useful, it would be commerical.
Which is why the pharmeceutical companies got special tax breaks for
developing "orphan drugs" that treat diseases that only a handful of
people get, to keep the cost of R&D down so the people could AFFORD
the drugs, right?

For it to be commercial, it needs to be both useful *and* have a sufficiently
large target audience to support a business. If your fixed costs are $1M,
and the marginal costs are $20/item, the economics work out a LOT differently
for 100K customers and for 100 customers. (Do the math yourself if you don't
believe me...)
V***@vt.edu
2003-10-08 19:58:22 UTC
Permalink
Post by Nicholas Weaver
If my external link is "ONLY" 100 Mb, and the latency/refresh time is
1 minute, thats 768 MB of data.
So who cares? Why juggle when shelves hold so much more?
Well.. sometimes, you need to store a small amount of data (20-30K of 0day
exploit or encryption key or similar, perhaps?) where people perusing the
bookshelf won't notice it.

I know of somebody who worked out a filesystem that used the "dead space"
between end-of-file and end-of-block to store data. Who cares? Somebody who
doesn't want it noticed.....
Michal Zalewski
2003-10-08 18:18:12 UTC
Permalink
Post by Nicholas Weaver
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.
Post by Nicholas Weaver
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.
Post by Nicholas Weaver
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/
Eugen Leitl
2003-10-08 20:13:14 UTC
Permalink
Post by Nicholas Weaver
There is a hypothetical Gb optical network link between here and the
moon, used for storage.
There's a considerable mileage of GBit/s (3 bit/m) fiber present, with
10 GBit/s (30 bit/m) consumer-grade networking in the pipeline, and ~TBit/s
(3 kBit/m) data rates feasible.
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
Fiber is perfect FIFO for packets in photonically switched networks.
That way you avoid costly photon-electron-photon conversion, and
can even achieve relativistic cut-through routing/switching with
proper header layout.

-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144 http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
der Mouse
2003-10-08 20:32:35 UTC
Permalink
Post by Nicholas Weaver
[...stuff about using the network as a delay-line storage
mechanism...]
[...]
So who cares? Why juggle when shelves hold so much more?
Because when you're storing something you don't want to be visibly seen
to be storing (typically something that's strong evidence of nefarious
activities - a simple example might be stolen credit card numbers) you
want a form of storage that disappears with few-to-no traces pointing
to you when law enforcement rolls through and seizes your computer.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Darren Reed
1970-01-01 00:00:00 UTC
Permalink
Post by der Mouse
Post by Nicholas Weaver
[...stuff about using the network as a delay-line storage
mechanism...]
[...]
So who cares? Why juggle when shelves hold so much more?
Because when you're storing something you don't want to be visibly seen
to be storing (typically something that's strong evidence of nefarious
activities - a simple example might be stolen credit card numbers) you
want a form of storage that disappears with few-to-no traces pointing
to you when law enforcement rolls through and seizes your computer.
deniable cryptographic storage
http://www.rubberhose.org

Darren

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Seth Breidbart
2003-10-08 20:42:32 UTC
Permalink
Post by Nicholas Weaver
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.
Nope.
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
It keeps the encryption (decryption) key safe from someone seizing my
computer.

Seth

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Rick Wash
2003-10-08 20:49:57 UTC
Permalink
Post by Nicholas Weaver
So who cares? Why juggle when shelves hold so much more?
Just because you and I don't have a use for this doesn't make it useless.

This technique has one advantage that I can see being very useful -- it is
easy to delete large amounts of data quickly. Imagine you hear the feds
knocking on your door -- you just unplug your fiber, and let all the light
(aka your data) fly out into the room. Your data is gone, permanently.
If the latency is a minute, then it only takes a minute to delete everything
-- all 6.5 GB of data according to your calculations. Show me another
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly. Hard drives need to be overwritten many times, but even then
they can still likely be recovered with enough money put toward it.

Rick

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Gary Flynn
2003-10-08 19:45:29 UTC
Permalink
While the paper presents an interesting concept and the practice
would certainly present forensics challenges, I suspect most
people in need of vast quantities of distributed, online storage
would simply use the population of Windows XP SharedDocs folders.


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Nicholas Weaver
2003-10-08 19:30:10 UTC
Permalink
Post by Alun Jones
Of course, a real network engineer would remind you that you face two
1. [UDP] Jugglers don't usually have to deal with oranges suddenly
disappearing in midflight, or being duplicated.
This can be handled, up to a point, by standard error-handling
techniques.

However, a little bit of back-of-the-envelope on an orthoginal access:
Measuring the latency (how long the object remains "in the network").


There is a hypothetical Gb optical network link between here and the
moon, used for storage.

The moon is ~3e8 m from Earth (384,000 km). Thus it is about 2
seconds of network latency from here to the moon.

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.

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!

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

So who cares? Why juggle when shelves hold so much more?
--
Nicholas C. Weaver ***@cs.berkeley.edu

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Alun Jones
2003-10-08 16:52:53 UTC
Permalink
-----Original Message-----
Sent: Monday, October 06, 2003 4:00 AM
A real juggler would focus on a different kind of outsourced data
processing, one that is much closer to his domain of expertise. Why,
distributed parasitic data storage, of course. - What if I write
a single letter on every orange, and then start juggling? I can then
store more orange-bytes than my physical capacity (the number of
oranges I can hold in my hands) is! How brilliant... But, but, would
it work without oranges?
Of course, a real network engineer would remind you that you face two
immediate problems regarding this technique:

1. [UDP] Jugglers don't usually have to deal with oranges suddenly
disappearing in midflight, or being duplicated.
2. [TCP] Jugglers don't have to hold onto a copy of their thrown orange
until such time as the catching hand lets them know that it's been caught.

Yes, networks can be used as storage, and in the very early days of
computing, "storage" was essentially a delay line with an amplifier -
whether this was an oscilloscope with an array of light sensors, or a coil
of wire, etc. This is roughly similar to the proposal under discussion.
Protecting network-borne data from corruption and loss is not a trivial
problem. Good luck.

Alun.
~~~~
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place | ***@texis.com.
Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Michal Zalewski
2003-10-08 17:53:41 UTC
Permalink
Post by Alun Jones
Post by Wojciech Purczynski
A real juggler would focus on a different kind of outsourced data
Of course, a real network engineer would remind you that you face two
1. [UDP] Jugglers don't usually have to deal with oranges suddenly
disappearing in midflight, or being duplicated.
Not really; the problem is trivially solved by maintaining a redundancy of
the data. Choosing the right parameters to maintain realiability is
perhaps the only challenge here, and it depends on the environment and
the set of bounce hosts.
Post by Alun Jones
2. [TCP] Jugglers don't have to hold onto a copy of their thrown orange
until such time as the catching hand lets them know that it's been caught.
No need to - the problem is solved by fire-and-forget + redundancy,
likening TCP to UDP; in addition, the paper proposes a method of storing
data using mechanisms such as a sustained command on the remote server,
where there is no need to resend the data on a regular basis, so even if
you use reliable TCP/IP stack, there is no need to keep any data for an
extended period of time on your end.

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

http://lcamtuf.coredump.cx/photo/current/
Adeel Hussain
2003-10-09 12:38:59 UTC
Permalink
In-Reply-To: <75a101c38dd8$40064170$***@watdougmoen>

Show me another
Post by Rick Wash
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly.
A ramdisk.
Doug Moen.
Section 7 of Peter Gutman's paper "Secure Deletion of Data from Magnetic and Solid-State Memory" touches on the fact that data can be retreived from RAM with varying degrees of success.

Corrections are always welcomed.

Paper available at:
http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/
Brandon Eisenmann
2003-10-10 02:58:34 UTC
Permalink
I don't in principal disagree that data can be recovered even from DRAM,
even powered down DRAM. I have yet to hear of a case where it has been
performed for forensic reasons. Academically there are quite a few
examples of techniques for recovering data from DRAM not to mention
SRAM. The Peter Gutmann paper you mention does cover the topic
briefly, for further reading I would suggest a later more technical
paper from him titled "Data Remanence in Semiconductor Devices". You
can find it at http://citeseer.nj.nec.com/gutmann98data.html.

Also Sandia Labs did a lot of research on retrieving data from
semiconductors. I can't think of any paper titles off hand but I do
recall finding a paper or two in the "IEEE Transactions on Nuclear
Science"

There has also been some talk about freezing DRAM before powering it
down to help maintain state and aid in data recovery.

All very interesting but other than extreme cases involving national
security I doubt that anyone would spare the expense. Especially law
enforcement or forensics investigators.

-Brandon Eisenmann
Post by Rick Wash
Show me another
Post by Rick Wash
method that can delete 6.5 GB a data in a completely unrecoverable manner
that quickly.
A ramdisk.
Doug Moen.
Section 7 of Peter Gutman's paper "Secure Deletion of Data from Magnetic and Solid-State Memory" touches on the fact that data can be retreived from RAM with varying degrees of success.
Corrections are always welcomed.
http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/
Continue reading on narkive:
Loading...