From: “Mark O. Aldrich” <maldrich@grci.com>
To: The Deviant <deviant@pooh-corner.com>
Message Hash: 8dcca7927d335f13b5a8f2803640772a2e67b644059a0a8f5aa8bf7dda13b2cc
Message ID: <Pine.SCO.3.93.960716103725.10319B-100000@grctechs.va.grci.com>
Reply To: <Pine.LNX.3.94.960716090027.5360D-100000@switch.sp.org>
UTC Datetime: 1996-07-17 16:07:10 UTC
Raw Date: Thu, 18 Jul 1996 00:07:10 +0800
From: "Mark O. Aldrich" <maldrich@grci.com>
Date: Thu, 18 Jul 1996 00:07:10 +0800
To: The Deviant <deviant@pooh-corner.com>
Subject: Re: Opiated file systems
In-Reply-To: <Pine.LNX.3.94.960716090027.5360D-100000@switch.sp.org>
Message-ID: <Pine.SCO.3.93.960716103725.10319B-100000@grctechs.va.grci.com>
MIME-Version: 1.0
Content-Type: text/plain
On Tue, 16 Jul 1996, The Deviant wrote:
> Mark Aldrich wrote:
> > The payload of getting false data out of a crypto algorithm, such that the
> > data looks "real", when a duress key is input to the algorithm is not
> > something that I've seen approached in any reasonable manner. Probably
> > because it's just too damn hard and the notion of "real looking" data is a
> > little hard to define scientifically. A combination stego/crypto solution
> > may be more appropriate, but close examination of the box is going to
> > reveal what happened (assuming the desired solution must withstand some
> > protracted forensics?). The nuke_the_data or nuke_the_keys solutions are
> > easier to do, and have been implemented in several situations of which I
> > am aware.
> >
>
> But, on the other hand, it wouldn't be to hard to have the user set both
> keys (yeah, so that didn't actually say anything, so what...), and then do
> an every-other-byte type thing (although that would be slow... every other
> block would be more efficient), and have 2 EFS's in one file, and make it
> so that on the "duress" one the extra space appears to be "free".
>
> One could make it a real file system, and add a fake disk error to prevent
> over-writing of the "non-duress" filesystem.
>
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. 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?
> > |the unfettered speech the First Amendment|MAldrich@dockmaster.ncsc.mil |
>
> This will sound odd, but did you know that "dockmaster" was the name of
> the NSA's first unclassified computer? just wondering.... ;)
>
It's not odd at all. That account is, indeed, on the NSA's unclassified
system. In my work, I sometimes support vendors taking products through
the NCSC evaluation cycle. The dockmaster box is the place where the EPL
records and other vendor materials are exchanged and/or published.
Dockmaster accounts are available for anyone who works in the INFOSEC
field, including private individuals. Quite honestly, it's of little use
(the OS sucks) unless you need up to the minute EPL and/or common criteria
stuff, etc.
-------------------------------------------------------------------------
|Just as the strength of the Internet is |Mark Aldrich |
|chaos, so the strength of our liberty |GRCI INFOSEC Engineering |
|depends upon the chaos and cacophony of |maldrich@grci.com |
|the unfettered speech the First Amendment|MAldrich@dockmaster.ncsc.mil |
|protects - District Judge Stewart Dalzell| |
|_______________________________________________________________________|
|The author is PGP Empowered. Public key at: finger maldrich@grci.com |
| The opinions expressed herein are strictly those of the author |
| and my employer gets no credit for them whatsoever. |
-------------------------------------------------------------------------
Return to July 1996
Return to “The Deviant <deviant@pooh-corner.com>”