Message-ID: <AANLkTi=nw_se-W8xW7aRDJj4AXjcWU+sNfh5biOK61U2@mail.gmail.com>
Date: Thu, 13 Jan 2011 16:36:01 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: Tomás Touceda <chiiph@...too.org>, 
	full-disclosure@...ts.grok.org.uk
Subject: Re: ESFS - The encrypted steganography filesystem

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.

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.

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.

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.


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.

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/
>

Content of type "text/html" skipped

_______________________________________________
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