Message-ID: <AANLkTiktFpLtKy+2GW3L3CzRCM7omJSQb_RAtmgHvmcD@mail.gmail.com>
Date: Thu, 13 Jan 2011 14:54:46 -0300
From: Tomás Touceda <chiiph@...too.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: ESFS - The encrypted steganography filesystem

Hi Peter,

2011/1/13 Peter Maxwell <peter@...icient.co.uk>:
> Hi Tomás,
>
> Not to be facetious but there are several generic problems with this concept
> (independent of implementation):
> i. A user will require your drivers to access their data and hence the
> presence of the drivers will alert any attacker to the potential of hidden
> data.  To hide the drivers creates a "chicken-and-the-egg" scenario.

True, but in this case you can erease the driver whenever you don't
use it. Say, if you want to save file A, you copy it to the ESFS
partitions, then erease the driver, and copy those images in a pen
drive, or whatever medium you want. When you want to retrieve it, you
can just download the driver and cat the file. So, may be the "FS"
part of the name is wrong, since you use it as a filesystem, but it
isn't intended to be there all the time. Currently, it uses a kind of
cache of objects in memory, so the idea isn't that while you are using
it, if someone is lurking through your RAM, he/she won't be able to
find anything, the protection will be present once you just have the
images.

> ii. Any file system will require a set methodology to store and retrieve
> data, which runs somewhat contrary to the idea of hiding data so that an
> observer cannot determine the existence thereof; in other words it is
> usually easy to check for standard structures.

I think I answered to this part above.

> iii. The presence of encrypted data is often obvious.  There are situations
> when you can hide encrypted data "in plain sight", e.g. products like
> TrueCrypt - afaik - use slackspace at the end of filesystems to store a
> second layer of encrypted data; the secrecy is provided by the property of
> most encryption algorithms producing data that is (ideally)
> indistinguishable from random data.  So for an attacker the data at the end
> of a FS could be either random data, or it could be a hidden partition.
>  However, if an adversary finds a TrueCrypt volume then they may just as
> well assume you are hiding another partition in there anyway and either
> detain you until you decrypt it, or torture you until you do.  Even if you
> have not created a hidden partition, your adversary doesn't know that and
> the safest course of action for them is to put pressure on you - in other
> words, you are either jailed/tortured regardless.  So the mere potential of
> having a hidden partition along with the inability to prove there is not one
> there could land you in a very problematic position.

Yes, if someone has in his mind that you are hiding something,
whatever, you can be tortured or put in jail, etc, etc, for no reason.
So nothing is perfect in this sense. Recent (and passed) history has
taught us that you don't need to be guilty to be accused of something
and be charged with it.

Be that as it is, ESFS isn't intended to be a replacement or a
competition to fine pieces of software as TrueCrypt. So if you intend
to encrypt your home directory, or the whole root partition, please
don't use ESFS. On the other hand, once we have work a lot more in
ESFS, and you want to save some files in kind of a "locker", *then* I
would say that you can use this.

> iv. Traditional steganography usually requires a massive amount of plaintext
> data in which to hide your secret, this will make any file system horribly
> inefficient, if not you end up using iii. with the problems outlined there.

Of course, the techniques I've used have their disadvantages. Right
now, yes, it's horrifly inefficient, but for now it's kind of a toy,
that may be with some time and hard work it will become a fine piece
of security software.

>
> In your implementation, I am not quite sure what the mechanism is: the
> "concepts" file is certainly not sufficient, and I'm not going to trawl
> through Python code to try and determine your design.
> Bottom line, and this isn't meant to be harsh, is that if you are designing
> a security product that you want others to trust then you must define it
> thoroughly and provide good arguments as to why it works.  Then they will
> test it and pull it to bits to determine whether it does what it says on the
> tin.  You have not done that here.

I tried to define it as thoroughly as I could, but evidently that
isn't sufficient yet. I'll work on that, thanks for pointing that out.
But, I'm not sure that "it works" from the point of view of something
that will assure the safety of your data. I've designed this as
careful as I can, but I'm not by far an expert in all this, so I've
probably missed a lot of things. That's why I made it public.

I'm learning here, I didn't planned to teach anybody anything with
this project, but I wanted to make it public so I can hear opinions
like yours, and learn from them. So, thanks a lot for taking your time
to answer.

Currently, someone I really respect and has a lot more experience that
I do in security, has accepted to audit the whole project. So I hope
with his hand and everybody else that wants to help us, we will make
ESFS a better project, or kill it completely if it's trash for real :)

Regards

> Regards,
> Peter Maxwell
>
>
> On 12 January 2011 19:08, Tomás Touceda <chiiph@...too.org> wrote:
>>
>> Hello everyone,
>>
>> I wanted to announce this little pet project that was born a couple of
>> weeks ago, and now it sees the light in the form of a proof of
>> concept, in hopes that it'll become a fully featured filesystem.
>> Here's an extract of the main README text:
>>
>>
>> ============================================================================
>>
>> What's this?
>>
>> Just like the title says, it's a filesystem. Particularly, it's a FUSE
>> filesystem that's implemented entirely in Python (for now), and it's a
>> proof of concept in alpha state, so don't save stuff only within this
>> filesystem just yet. A couple of weeks ago, I started reading about
>> and playing with encrypted filesystems (LUKS + dmcrypt, encfs, etc). I
>> came across an email (actually, a friend of mine tossed me the link)
>> from the now well-known Assange, about a Linux kernel module he and
>> other people were working on that provided different layers of
>> encryption in a filesystem, so you can say "oh, yes, I have encrypted
>> data in here", but in a deeper layer you'd have more encrypted data,
>> with another key, and nobody but you would know about it. And I
>> thought it was a really cool idea. I started looking for the code, but
>> it was too old to be used with the current kernel. A couple of days
>> before that, I read about StegFS, a filesystem that uses steganography
>> to hide your files within your other files. And again, I thought it
>> was a really cool idea, BUT I didn't like the fact that (and please
>> correct me if I'm wrong) when you copied a file in StegFS, there's a
>> chance you'll lose some other file. So, this one is usable, but this
>> drawback didn't suit me. I started bouncing ideas with a lot of
>> friends, and then it hit me: a filesystem, hides its data in images
>> and encrypts this data. I wanted to build a FUSE filesystem since I
>> first learned about it, so I finally had an idea to work with. This
>> idea gives you the same advantages of Assange's kernel module: you
>> have a bunch of images that seem like regular files, but when you
>> mount the filesystem with certain parameters BAM! you have lots of
>> files that nobody knew were there.
>>
>>
>> ============================================================================
>>
>> You can find the rest of this README, a more detail design document,
>> and the actual code in: https://github.com/chiiph/esfs
>>
>> If you find any bugs, please let me know.
>> Any comments and critics are more than welcome.
>>
>> Regards,
>> --
>> Tomás Touceda
>> Gentoo Developer
>> Herds: Qt, Scheme, Lisp
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>



-- 
Tomás Touceda
Gentoo Developer
Herds: Qt, Scheme, Lisp

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists