1996-07-18 - Re: Opiated file systems

Header Data

From: The Deviant <deviant@pooh-corner.com>
To: Adam Back <aba@dcs.ex.ac.uk>
Message Hash: 08a31fd166f6782c1ff49bbe93a35117d7dad792722908233fd646d37c301b71
Message ID: <Pine.LNX.3.94.960718015546.9976B-100000@switch.sp.org>
Reply To: <199607171103.MAA00222@server.test.net>
UTC Datetime: 1996-07-18 05:34:45 UTC
Raw Date: Thu, 18 Jul 1996 13:34:45 +0800

Raw message

From: The Deviant <deviant@pooh-corner.com>
Date: Thu, 18 Jul 1996 13:34:45 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: Opiated file systems
In-Reply-To: <199607171103.MAA00222@server.test.net>
Message-ID: <Pine.LNX.3.94.960718015546.9976B-100000@switch.sp.org>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 17 Jul 1996, Adam Back wrote:

> Date: Wed, 17 Jul 1996 12:03:46 +0100
> From: Adam Back <aba@dcs.ex.ac.uk>
> To: jpb@miamisci.org
> Cc: maldrich@grci.com, deviant@pooh-corner.com, WlkngOwl@unix.asb.com,
>     cypherpunks@toad.com, aba@dcs.ex.ac.uk
> Subject: Re: Opiated file systems
> 
> 
> Joseph Block <jpb@miamisci.org> writes:
> > At 10:44 AM -0400 7/16/96, Mark O. Aldrich wrote:
> > >One problem, however, would be how to keep the "decoy" data, accessible
> > >with only the ambush key, "fresh" in that it must undergo a certain amount
> > >of turbulence to appear real.
> 
> A problem yes.  My thoughts were that you would effectively have two
> filesystems and use them both yourself for real work.  That is to say
> that you would say have some consulting work doing some programming or
> something, and use the 1st encrypted filesystem for this work.  If
> this work was covered by an NDA, so much the better, as it would
> provide an understandable reason for encrypting.

Good Idea, but I also like the idea of selective-duress, i.e. not
necisarily having a duress key at all.

> 
> > >The two file systems would essentially have to
> > >mirror each other, one with the juicy bits and one with the decoy bits.
> > >It would seem to be practically impossible to just build two file systems
> > >as one would 'disappear' when only the ambush key was used.  Wouldn't it
> > >be sort of obvious that something was wrong if half the disk vanished?
> 
> I don't think nuking the data is the way to go, from what I understand
> of the way these things work, is that they kick down the door in the
> dead of night and make sure you don't get to touch the equipment.
> Also they'd be sure to take a sector level backup of the drive as a
> first step.

I have several friends that this has happened to, and pretty much it goes
like this... round 7:00 AM, when your just going to bed (well, some of us
don't have jobs till nighttime.. thank god.), they knock down your doors
and windows (yes, they do come through windows), and they take the
equipment, disks, tv's, CD players (yes, i know somebody who had their CD
player taken.  And a pile of CDs. Music ones even.), clock radios, pretty
much everything electronic they can cary.  If you ever DO get any of it
back, most likely it is not the same equipment, i.e. they coppied it all
and kept the original.

I do agree that nuking the data isn't the way to go.  Most of the time if
you crypted something, you're probably gonna want it back.

There's also an Idea me and Mouse had, which is to have a fault-tolerant
duress system.  Its something like this...  You have a Duressfs and a
Non-Duressfs.  If they enter the duress key is entered wrong, but only by
a certain percentage of characters (i.e. sex instead of hex), it lets you
see the Duressfs.  If you do this too many consecutive times, it runs the
DuressNuke function (optional?).  If you put the Duress key in correctly
it runs the DuressNuke function.  If you put the secret key in, it gives
you the non-Duress version.

that way if they didn't beleive you're "near-duress" key, you can give
them the actual duress key to nuke the data.

Just an idea.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBMe2dpzAJap8fyDMVAQF4tgf9F0urSb+4D/Cwl4eb4Y5t1FeGEt5FEmDZ
irKOo8ndGj22f0Qb3QEaAaVz85t41YG85FuG3eTsTEUDQmKi/YSqvlo0zgaIJ0tb
/xLMSiFWEWoekxChzXoJtR8XSVc+wOmxLSBWCa73JjU4YPdYLtYdgK2C0E3wNfWF
WoSGe18FnejnrdvSnlF2rpF1wFgYnRrArlRvCZpmDp8bZAhm0rhLqOZ7MyVoUBjA
TKPzNVtskEYsNWQZ6eMrIJHHCUEzQ7IrUoWjP5v4QOQOxngijkgkpZZINMvVCp/e
k7aoot75XoUk23cPgGucR63r8jz+T1s/usBxuIYSE7ZujnpJ+Q10rA==
=/nXP
-----END PGP SIGNATURE-----






Thread