1996-07-19 - Re: Opiated file systems

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: WlkngOwl@unix.asb.com
Message Hash: 86ffc0ce2af120e69f45979ed2c8cd314233e7cc1d0271e61f618b9b09bd4d65
Message ID: <199607182148.WAA00324@server.test.net>
Reply To: <199607172125.RAA09158@unix.asb.com>
UTC Datetime: 1996-07-19 02:44:06 UTC
Raw Date: Fri, 19 Jul 1996 10:44:06 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Fri, 19 Jul 1996 10:44:06 +0800
To: WlkngOwl@unix.asb.com
Subject: Re: Opiated file systems
In-Reply-To: <199607172125.RAA09158@unix.asb.com>
Message-ID: <199607182148.WAA00324@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain



Rob <WlkngOwl@unix.asb.com> writes:
> On 16 Jul 96 at 19:21, Mark M. wrote:
> > > A problem with a c'punk-style encrypted fs with source code and wide 
> > > distribution is, of course, that attackers will KNOW that there is a 
> > > duress key.
> > 
> > I don't see how this would effect the security of such a filesystem.
> > There is absolutely nothing that an attacker can do to get the real
> > key.  An attacker would just ignore all computers that have duress
> > key capability.
> 
> [attack on duress system]
>
> 3. reverse-engineer file system driver to figure out how the
> duress-key works,

I thought the presumption was that source code was provided (for the
duress feature too)?

The whole system should be designed to withstand scrutiny as to
whether or not there is a duress file system on any given disk, on the
assumption that the opponent as full access to the source.

ie. the attacker can not tell without the hidden file system key (if
one exists) whether the unused space on your drive is really just
that: unused space filled with garbage, or whether it is in fact
another encrytped filesystem.

They might be suspicious, but I don't think they would be able to
claim you were in comptempt of court, if you provide the 1st key and
claim there is no other key: the software has support for either 1 or
2 filesystems.

Adam





Thread