NODE 4f5fcb16Re: Opiated file systems
"Deranged Mutant" <WlkngOwl@unix.asb.com>Sat, 20 Jul 1996 21:24:55 +0800
On 18 Jul 96 at 11:01, Adam Back wrote:
> For plausibility it would probably be best if very few people used the
> duress key feature.
And how can you guarantee that? Also: an attacker doesn't care about
what percentage of (other) users use duress feature of not. His
concern is whether you use it.
Note that you'd have to be careful of what you say and do over email
in the clear (or encrypted to someone cooperating with an attacker):
if you post an excerpt of source code or maybe somehting like
Edupage, or if you save mail, there might be reason enough for the
attacker to expect to see some of that on your encrypted fs after
he's rubber-hosed your key from you. If he doesn't, and he knows you
have a possibility of using the duress-key feature...
Oh yeah. Psychology is a good way of determining the likelihood of
using a duress system.
With the extra work and overhead of a duress system, you're better
off using stego on some gifs or graphics files.
Rob
---
No-frills sig.
Befriend my mail filter by sending a message with the subject "send help"
Key-ID: 5D3F2E99 1996/04/22 wlkngowl@unix.asb.com (root@magneto)
AB1F4831 1993/05/10 Deranged Mutant <wlkngowl@unix.asb.com>
Send a message with the subject "send pgp-key" for a copy of my key.
NODE 7f8d849dRe: Opiated file systems
Adam Back <aba@dcs.ex.ac.uk>Sat, 20 Jul 1996 15:30:12 +0800
Rob <WlkngOwl@unix.asb.com> writes:
> On 18 Jul 96 at 11:01, Adam Back wrote:
>
> > For plausibility it would probably be best if very few people used the
> > duress key feature.
>
> And how can you guarantee that?
User apathy, people not reading documentation, documenting it as an
advanced feature... etc.
How many people actually generate a PGP key revocation cert in advance
in case of losing the key for instance?
> Also: an attacker doesn't care about what percentage of (other)
> users use duress feature of not. His concern is whether you use it.
Good point. But what other data does the attacker have aside from how
many others do? Even knowing how many others do would be
tricky.. are they telling the truth when they say they aren't?
> Note that you'd have to be careful of what you say and do over email
> in the clear (or encrypted to someone cooperating with an attacker):
> if you post an excerpt of source code or maybe somehting like
> Edupage, or if you save mail, there might be reason enough for the
> attacker to expect to see some of that on your encrypted fs after
> he's rubber-hosed your key from you. If he doesn't, and he knows you
> have a possibility of using the duress-key feature...
Smart analysis, yes you'd have to be very careful to partition the way
you used the two file systems. You'd have to pretend that the 2nd
partition did not exist when comunicating with any one who you didn't
trust. Perhaps you could have some assistance even... making the
duress file system read only when you have the hidden fs mounted as an
option to remove the chance of accidentally copying something from the
hidden fs that you couldn't (otherwise) explain being your possesion?
Someone cooperating with the attacker could be tricky though,
ultimately there's not much you can do about infiltration aside from
always using a nym for correspondence to do with your hidden persona
which goes with your hidden fs.
> Oh yeah. Psychology is a good way of determining the likelihood of
> using a duress system.
Hmm, the psychological aspect of your plausible deniability. Don't
think cryptographic protocols can do much about that.
> With the extra work and overhead of a duress system, you're better
> off using stego on some gifs or graphics files.
But I don't think stego solves your whole problem: you still have to
have software to access the stegoed data. Where do you store this?
Nearly back to square one. (If the answer is on a floppy this applies
equally to a duress file system).
The one advantage of stegoed data is that you expect the least
sig. bits in image files to be random, where-as you don't expect the
LSBs in unused space (even in encrytped file systems once you're
inside the encryption layer) to be random.
However the disadvantage is 8 - 24 times reduction in space
efficiency. (Your earlier point).
Adam
NODE 1a1904baRe: Opiated file systems
JonWienk@ix.netcom.comSun, 21 Jul 1996 04:56:51 +0800
Here is an idea for implementing DuressSFS and/or NukeTheData functions on
demand with plausible deniability for all (without all your keys, TLA's wouldn't
know how many encrypted partitions you had:
1. Doing anything with the encrypted file system requires 2 keys.
2. The first key decrypts the FAT (the FAT info is always written to the disk
encrypted) and an encrypted control sector, which is cylinder 0, head 0, sector
JustAfterTheMBRAndPartionTable. This control sector is divided into 16 32-byte
(256-bit) fields or records.
3. If a hash of the key entered matches the undecrypted contents of record 0,
(bytes 0-31) the EFS enters an infinite whole-drive encryption loop, using a
hash of the key provided and any handy entropy, to produce a new key. The EFS
will produce new keys as frequently as possible by hashing any entropy it can
gather while nuking the data on the drive. While this is happening, dummy
messages should be displayed, such as "Starting Windows 95...", "An exception
has ocurred at XXXX:XXXXXXXX Press any key to continue." (when the entropy
stock needs replenishment) or any other reasonably common startup messages.
(NukeTheData) (TM)
4. If the first key is not the NukeTheData key, the EFS prompts for a second
key.
5. After receiving the second key, the EFS hashes it and compares the hash to
the data in the control sector records, and mounts any encrypted logical
drive(s) with matching key hashes.
6. If an incorrect second key is entered X times(X between 3 and 20),
(NukeTheData = True) is assumed, and executed.
Using this system, without the first key, it should be impossible to tell how
many separate encrypted logical drives there are on the disk. Without the second
key(s) the data in the ELD's should be worthless. On bootup, the pass phrase
entry screen should be designed to look exactly like the CMOS bootup password
screen, and no messages indicating the existence of EFS should be displayed
until after a correct 2nd key has been entered. Why advertise your security
measures? Unless "they" have been tipped off to the fact that you use EFS, they
can easily destroy all of the data through ignorance, especially if you have a
PostIt note with the NukeTheData password/phrase (which wouldn't have to be
"good"--you could use "GovtStupid" or something similar) stuck to the side of
your monitor, and keep your mouth shut during interrogation.
Jonathan Wienke
"1935 will go down in history! For the first time a civilized nation has full
gun registration! Our streets will be safer, our police more efficient, and the
world will follow our lead in the future!"
--Adolf Hitler
"46. The U.S. government declares a ban on the possession, sale,
transportation, and transfer of all non-sporting firearms. ...Consider the
following statement: I would fire upon U.S. citizens who refuse or resist
confiscation of firearms banned by the U.S. government."
--The 29 Palms Combat Arms Survey
http://www.ksfo560.com/Personalities/Palms.htm
1935 Germany = 1996 U.S.?
Key fingerprint = 30 F9 85 7F D2 75 4B C6 BC 79 87 3D 99 21 50 CB