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]
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Re: [PAPER] Juggling with packets: floating data storage

On Wed, 8 Oct 2003, Nicholas Weaver wrote:

> You have some refresh time required, just like DRAM or any other
> lossy/decaying medium.

Not really, per the whitepaper. Some storage points may indeed "decay" by
going down, but this is not necessarily a sizable population; there is no
need to refresh data on hosts that stay alive.

Once again:

  - Send data to the remote host once,

  - Have it kept on the remote host as long as you wish with a
    very low "data sustain" traffic (ACK packets with \0 payload);
    you can do it for as long as the storage host stays on-line;
    when it goes off-line, you can detect it and pick another
    storage target (granted you've deployed some redundancy and
    can recover the data from other source).

That's what we proposed. And if you look at our calculations, even if you
take them with a grain of salt, it is possible to store plenty of data
this way even on a poor link.

> With a 100 Mb refresh bandwidth, thats 1 TB.  I can go out and buy a box
> which holds nearly 1 TB for <$2000.  Heck, I can buy a >2 TB RAID array,
> FROM APPLE (hardly a low price vendor) for $11k!

Once again, not the point. This storage shares very few properties with
non-volatile media such as disk drives, and is hardly practical for
storing warez (although in some cases, it can be - not for a person with
100 Mbit uplink, but for a guy with a low-end modem or DSL).

> The refresh rate is required for parasitic storages, to prevent data
> decay and to recompute checksums etc to handle data loss.
> Even given a 1 WEEK refresh cycle

...which is a very low assumption, granted that it is not a problem to
find a sizable population of web servers and other systems that have
uptimes reaching months... and still has nothing to do with the fact that
(limited) deniability, assured destruction on disconnect storage media may
have some interesting privacy implications, and this is what we try to
point out in the paper.


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

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


Powered by blists - more mailing lists