[Noisebridge-discuss] M.A.I.D. was: Freespace / slackspace file system

Jacob Appelbaum jacob at appelbaum.net
Thu Sep 24 08:52:22 UTC 2009


Sai Emrys wrote:
> I'm curious whether this is possible and/or already done.
> 
> The idea: have a file system that lives entirely in the free space
> and/or slack space of another file system.

[...]

> 
> The closest I can think of is Truecrypt, but it doesn't really do this
> at all (except the crypto, which it does quite well); it requires
> outright ownership of its file / partition / psuedo-partition. I want
> this to live within the gaps of a preexisting one.

Many years ago a number of cypherpunks worked on this very problem. The
solution that was created is a strong, well written but sadly abandoned
project called the Rubber Hose File System:

http://iq.org/~proff/marutukku.org/
http://en.wikipedia.org/wiki/Rubberhose_(file_system)

It's described in a review by Steven Baum as:
"Rubberhose is a deniable cryptography package that lets someone not
wanting to disclose plaintext data corresponding to their encrypted data
show that there is more than one interpretation of the latter."

"Rubberhose works by initially writing random characters to an entire
hard drive or other dynamic storage device. This random noise is
indistinguishable from the encrypted data to be stored on that disk. If
you have a 1 GB drive and want to have two Rubberhose encrypted portions
of 400 MB and 200 MB, it assumes that each aspect (as the encrypted
partitions are called) will be 1 GB and fill the entire drive. It will
keep doing this until the drive is really filled to capacity with
encrypted material. It breaks up the pieces of each aspect into small
pieces and scatters them across the entire 1 GB drive in a random
manner, with each aspect looking as if it is actually 1 GB in size upon
decryption."

"Each aspect has its own passphrase that must be separately decrypted,
and if a hard drive is seized neither mathematical analysis nor physical
disk testing can reveal how many aspects actually exist. Internal maps
are used to locate where the data is stored amongst the random
characters, with each aspect having its own map which can only be
decrypted via its specific passphrase. As such, a Rubberhose disk only
be written to after all the passphrases have been entered. Everything is
works on a "need to know" basis, i.e. each aspect knows nothing about
the others other than when to avoid writing over the top of another."

Some of the choices are rather dated. They don't offer AES. It was
created before Rijndael was AES. I think it was published before
Rijndael was created too.

It was created by Julian Assange. Julian is a talented hacker who also
is involved in other amazing projects such as Wikileaks. That he was
involved really speaks quite highly of the project. Another member of
the RHFS team actually visited Noisebrige during this last summer, they
can shed their anonymity themselves in this thread if they'd like.

These days, I hear that people often use straight disk encryption. You
may have heard that Noisebridge has done some research into this field
of study. If there's interest, I could probably dig up some slides and
we could have a discussion group.

Generally, I believe that you want to read about Deniable Encryption:
http://en.wikipedia.org/wiki/Deniable_encryption
http://en.wikipedia.org/wiki/Deniable_encryption#Software

The related fields are also interesting:
http://en.wikipedia.org/wiki/Plausible_deniability
http://en.wikipedia.org/wiki/Deniable_authentication
http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

By and by, I think that this idea is really great in theory. However, at
the 22C3, I introduced the concept of a law hack called M.A.I.D.; the
idea is essentially the inverse of a rubber hose file system. I called
it M.A.I.D. because "it cleans up after you when you're not around." The
acronym stands for something like 'MAID is (Mutually) Assured
Information Destruction'.

The RHFS gives you an ability to give up passwords and no one can prove
that you haven't given all of the possible keys. So you can give
passwords and then cave in and eventually you'll 'break' giving them the
really secret key. But in actuality, you're a tricky guy and you kept
the real secret secret, etc.

I think that assuming that they're not going to kill you when they "win"
anyway, it may make no sense to go through all of the torture. In some
cases, you may have the rule of law on your side and you may be able to
simply to wait for a trail. If you do this, you can simply have a key
that expires. You can fully comply with the law, telling a password when
required by a court. This might be desired when there are laws like the
UK Rip Act at play in a given case. It's possible to disclose the
password because the system automatically expires the key. You can't do
anything with the password after it's expired. The password _you know_
is totally unrelated to the cryptographic keying material for _the
encrypted disk_. So what's the password for? It's used to unlock an
authentication token. The token is used to authenticate to a trusted
remote system.

Thanks to Tor hidden services, it's possible to have a remote server
that's _very_ hard to seize. With a careful setup, you may be able to
avoid seizure entirely. That makes the remote key storage an affordable
proposition. It also creates a requirement for anonymized clients. The
server doesn't really know anything about the client and with proper
binding, you can do some neat crypto tricks to ensure you mutually
authenticate, mutually have some kind of trust, etc.

The keys are returned over a secure channel. The user never sees those
keys. The user knows as much about those keys as they understand the
inner workings of AES. Those keys unlock a given partition. You could
even combine this with Rubber Hose FS if you like some of their other
design ideas. I think that's potentially a bad choice. I guess it's also
a bad idea to admit you may have a backup. You probably see the pattern.

I have all of the ideas written down (there's a lot of other stuff
including remote distress codes, etc) but I never seriously worked on my
implementation. If someone was interested, I could probably write the
entire thing in a week. The hard parts are largely solved problems, the
main point of M.A.I.D. is sewing those things together.

Best,
Jake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20090924/456e7929/attachment-0003.sig>


More information about the Noisebridge-discuss mailing list