1996-07-19 - Re: Opiated file systems

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: frantz@netcom.com
Message Hash: 906b6f79c020127c5c1d43030ef96b2cbbcb77acee0786bee1bd51f8588777d2
Message ID: <199607182219.XAA00332@server.test.net>
Reply To: <199607180630.XAA29062@netcom8.netcom.com>
UTC Datetime: 1996-07-19 02:25:32 UTC
Raw Date: Fri, 19 Jul 1996 10:25:32 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Fri, 19 Jul 1996 10:25:32 +0800
To: frantz@netcom.com
Subject: Re: Opiated file systems
In-Reply-To: <199607180630.XAA29062@netcom8.netcom.com>
Message-ID: <199607182219.XAA00332@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain



Bill Frantz <frantz@netcom.com> writes:
> At  1:30 PM 7/16/96 -0700, Jim Gillogly wrote:
> >"Deranged Mutant" <WlkngOwl@unix.asb.com> writes:
> >>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.
> >
> >Good point.  This suggests a design desideratum for any such system should
> >be that the user may choose not to have a duress key, maintaining
> >semi-plausible deniability for those who choose to have one.
> 
> Perhaps a user settable number of duress keys with different behavior for
> each of them?

I'm not sure what you had in mind for differing behaviours (were you
thinking nuking of data variety?), but I think the option for multiple
hidden file systems may be a feature some people would want.

However, I think it would greatly reduce an individuals plausible
deniability of there existing a 2nd hidden file system, if they admit
to a 1st hidden file system.  They have admitted that they are willing
to play the duress key game, so what's to say they haven't done it
again.

Adam
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)





Thread