// COMPLETE THREAD

Re: Opiated file systems

3 expanded posts ยท every known parent and child

NODE 4f5fcb16Re: Opiated file systems
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
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
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