Opiated file systems
On 14 Jul 96 at 12:48, Adam Back wrote while high on Ritalin:
Some more thoughts on encrypted file system design criteria. A wish list:
- Choice of secret key encryption algorithms (IDEA, 3DES, MDC, Blowfish)
Nice in theory. Awful in practice. Requires code for managing keys, encrypting and decrypting for ea. algorithm be resident in memory. For some systems (MSDOS), free memory is at a premium... (one of the reasons SecureDrive is popular is because it takes only 2.5k). It's not worth wasting memory for handling several algorithms when only one is going to be used in most cases.
- Multiple architectures (MSDOS, Win31, Win95, WinNT, Unix, Mac)
Ok...
- High performance (hand optimised assembler for each architecture)
So much for maintaining code across platforms.
- Compression
Not worthwhile. Use a Stacker or JAM driver over the encrypted partition on a PC, for instance. Keep compression and crypto separate utilities... keeps bugs from one interfering with another and reduces complexity of both drivers; also, if one wants crypto w/out compression or compression w/out crypto, no wasted memory (see above about RAM being at a premium).
- Ability to chain algorithms (IDEA and then 3DES for example)
Why? Doesn't necessarily increase security, esp. considering the performance hit (memory... see above, time, key management).
- Possible to have encrypted file systems on separate partitions, or
- Encrypted file system located in a file in another file system (much like DOS stacker drives) this is an ease of use criteria -- I suspect re-partitioning drives would put off many potential users.
Nothing new there.
- Ease of use. Graphical user interface for setup and administration functions, with a very simple set of configurations options displayed by default, with more advanced configuration options available in "expert" mode.
A common problem with much crypto these days.
- All directory and FAT information should be encrypted, so that it is not possible to discover even number of files, or percentage of disk used without the key
Do you understand how such systems work?!? Every sector is encrypted in such systems. That's not even an issue for most encrypted file systems (at least on the PC).
- Facility for duress key, with the real data hidden in the unused space of the first encrypted drive. To increase the plausible
Huh?!?
deniability all unused blocks within a file system should be filled with garbage, so that it is not possible to tell if there is more data there.
If the algorithm is good, this shouldn't matter. The only way a person could tell if a sector is unused is if that person was able to mount the partition already.
- File system steganographically hidden in files on another file system (encrypted or not). Support for a wide selection of file formats (Aiff, Wave, Midi, JPEG, GIF, RGB, MPEG).
Now this is getting nutty!!! Never mind the size, compleixty and amazing slowness of such a driver... you'd have to have audio or video files of gigabytes in size to be able to store anything of use.
- Ability to use stegoed file system in files on an unencrypted file system, and boot from a floppy to access stegoed file system, with no other traces left on hard disk.
Why? The authorities would wonder why you have an 8 Gig JPG on your disk and figure you're using it for stego, or you're crazy, or both, and have you committed. Rob.
On Mon, 15 Jul 1996, Deranged Mutant wrote: <snip - much stuff on crypto device drivers for disk subsystems deleted>
- Facility for duress key, with the real data hidden in the unused space of the first encrypted drive. To increase the plausible
Huh?!?
Hey, DM, don't laugh. I've gotten such requests before about crypto subsystems, including tokens with "protected" keys onboard. The idea is that there's a "duress key" or a "panic key" that, when entered, fools someone into thinking the process is working but, in fact, it's not working at all and it usually is doing something else (like scrubbing the hard disk, scrubbing the key PROM, or calling the police). I've worked at sites that have their electronic door locks rigged the same say. The way it works is, let's say a terrorist has a gun to your head and demands, "let me in the door or I'll blow your head off." Naturally, the Government doesn't want you to have to choose between dying and giving out the cypher lock combination (guess which one people choose in blind testing?), so you put in the "duress code." The door unlocks so the terrorist thinks that all is well. However, the alarm just went off over at the security substation and, in about two minutes, a heavily armed SWAT team will be arriving. Same for cypto keys, but with a different "payload" if the duress key is used. The data either gets "nuked" (Gosh, Mr. FBI Agent, I *thought* that was the right crypto key - sorry about destroying the hard disk), the keys disappear (damn! my fortezza card just zeroized again!), or the data appears to "decrypt" but it's actually phoney data that's been hidden somewhere or is 'hard-coded' into the program handling the duress key. 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. ------------------------------------------------------------------------- |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. | -------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- On Mon, 15 Jul 1996, Mark O. Aldrich wrote:
Date: Mon, 15 Jul 1996 17:43:28 -0400 (EDT) From: "Mark O. Aldrich" <maldrich@grci.com> To: Deranged Mutant <WlkngOwl@unix.asb.com> Cc: Adam Back <aba@dcs.ex.ac.uk>, cypherpunks@toad.com Subject: Re: Opiated file systems
[Usefull stuff >/dev/null]
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.
------------------------------------------------------------------------- |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. | -------------------------------------------------------------------------
This will sound odd, but did you know that "dockmaster" was the name of the NSA's first unclassified computer? just wondering.... ;) --Deviant -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMetbfTAJap8fyDMVAQGN7Af+Jck2zofxtJOBLuceEhGmaZwoodxGHITb PrdLwsrYVdWbyzhtmCy9iDm0cMh0BW6dRGXDQWml4Ed0ObAPBwQz4wwpbS+4OOBS VSsTQ+A5JctbxeaA24XPPCbVOLrCCFaWiNZacSft/hUPDn4etYPKwtVDFfFsKtWF VohL28TyLAskNUFarKKr1YFVAlZ632XZy9xEDXnNi7lDwj5cSHtCL89Kt0F8qSiq 6Qz+cfWmwpx4Pv/CyenTUHu+Q6orgxSGIY7hBGywcUzm4lRKmOJrzFjqjM3Af4dQ 78lasplnScvu2Pw6ofCxFBHpf0r4DH/XdeKH0BzKoQnBlu8X4bjg0A== =/T4e -----END PGP SIGNATURE-----
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. | -------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- On Tue, 16 Jul 1996, 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. 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?
While you do have a valid point about the turbulance needed, I think you could still make some reasonable enough errors on the fakefs. One could simple have several "curropt I-node tables", and that would satisfy almost anybody (the NSA doesn't do domestic work ;) --Deviant -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMe1GlDAJap8fyDMVAQHUiwf/Tc1Oq8qxx6Q9T5r57RHaDIyDaANKkUas 1VvVR2eCMlfDQAvUAFbGELEErKRTQnb+JCF9QoCH/eLrAnFcKrk+4hbcONimongO X3wTUn3PXhQSoF3XH7u9F13npo0cAWavmlJD+16uTFxtyzt211u/APuxHrT/9jWx mgvQtgMwkqNJICSlIRHAL4pQJ6pe1cweR8t0UxpKy55WtQzsdyF2Yh3fYSDvyaaa L3m9qaa2QBuuLpPr7Bd5iCGlsPiyv2lo73FF9biYiKOTbo1lIKX5Sy5ITJVBFmrM tfw7ZCxoe281k0jyyO3524Vycd5VOBOfE0atgHfMClI/E7AH9v43FA== =chgf -----END PGP SIGNATURE-----
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. 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?
As far as churning goes, why not just mount both the decoy and the encrypted filesystems simultaneously? Have a perl script (stored on the hidden volume of course) that automatically decodes random images from alt.binaries.pictures.* into the decoy system and nukes the oldest decoy files. And go ahead and keep a copy of all your assorted /var/named & other config files in there too. Honest officer, I keep that partition unmounted so that a system crash is less likely to clobber my painfully constructed configuration files - and it's encrypted so that crackers won't be able to alter my configuration backup to add security holes. Let them go nuts trying to un-stego the smut images once you've given them the duress key. Joseph Block <jpb@miamisci.org> "We can't be so fixated on our desire to preserve the rights of ordinary Americans ..." -- Bill Clinton (USA TODAY, 11 March 1993, page 2A) PGP 2048bit-Fingerprint: F8 A2 A5 15 56 42 9B 16 3F BD 57 0F 8A ED E3 21
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.
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. If you have your duress encrypted file system, with the "real" file system in the unused space of that filesystem, and the hidden file system is encrypted with an unknown (to them) 3DES key, I don't see how they are going to be able to prove that it is not just noise. (This is presuming it is a feature of this encrypting file system that it ensures unused space is always filled with noise anyway, even inside the first layer of encryption) The question of freshness Mark raised, if I understand correctly is interesting. I presume here he is talking about the fact that under analysis it is possible to retrieve information from hard drives which has been deleted and overwritten even multiple times with other data, due to the relative inaccuracy of disk head placement, and other factors. Perhaps it is even possible to tell how recent a magnetic pattern is even? In an encrypted file system with no hidden file system, if the unused space were filled with random garbage, you might expect that garbage to have been modified fewer times, or less recently than the real data. If there were a second hidden file system in those unused blocks, it might show up due to being written to more recently, or more often than expected. If the threat model includes this kind of analysis, I think it would be necessary to ensure that all the data is churned evenly, or sufficiently that there is little chance of extracting this kind of information. What I would suggest is that during periods of disk inactivity the data (even the unused space whether it is a 2nd partition or not) is re-encrytped with a new random IV at some frequency. The frequency chosen should be to ensure that all the data on the disk is recent, and that in the course of disk usage over a period of a week there are many re-writes with data re-encrypted with random IVs to all areas of the disk.
As far as churning goes, why not just mount both the decoy and the encrypted filesystems simultaneously?
I think you would have to mount them both during normal usage to avoid damaging the real filesystem hidden in the unused space. Only in the event of a duress situation would you mount only the duress file system. This next bit must be talking about the stegoed file system:
Have a perl script (stored on the hidden volume of course) that automatically decodes random images from alt.binaries.pictures.* into the decoy system and nukes the oldest decoy files.
Careful. For stego you can't use publically available images -- they have to be images you scanned yourself, other-wise comparison will show that the images have been altered. (Law enforcement agents read a.b.p.* too). 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*',/((..)*)$/)
-----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-----
<deviant@pooh-corner.com> writes:
On Wed, 17 Jul 1996, Adam Back wrote:
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.
That was my meaning: either 1 or 2 filesystems, at the users option, and for the file system to look the same to anyone not holding the 2nd key (if there is one) whether or not there is a 2nd hidden file system.
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?).
More subtle than straight nuke the data, but still they'll have the backup, and the code to reverse-engineer. Another idea might be to have secret shared keys to your encrypted fs, so you can't access your file system without your friend(s) co-operation. That would give your friends an opportunity to nuke their share of the key before they got their dawn raid. You could automate the nuking, with some pre-arranged policy for key destruction (eg the computers could bounce messages off each other, and if this stops the key-portion gets nuked). However, the opposition is already one step ahead: simultaneous dawn raids were the fad during operation Sun-Devil, just in case of such schemes I presume. 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*',/((..)*)$/)
Rob <WlkngOwl@unix.asb.com> writes:
Some more thoughts on encrypted file system design criteria. A wish list:
- Choice of secret key encryption algorithms (IDEA, 3DES, MDC, Blowfish)
Nice in theory. Awful in practice. Requires code for managing keys, encrypting and decrypting for ea. algorithm be resident in memory.
No need to have all the code in memory, I think you ought to be able to keep the code in an overlay, or something of that nature.
For some systems (MSDOS), free memory is at a premium... (one of the reasons SecureDrive is popular is because it takes only 2.5k). It's not worth wasting memory for handling several algorithms when only one is going to be used in most cases.
I take your point about memory consumption under DOS, though presumably it would be possible these days to load data high. I think SFS supports this for instance.
[...]
- High performance (hand optimised assembler for each architecture)
So much for maintaining code across platforms.
Only the secret key algorithms, 80x86 code would be the highest priority coz they're the slowest (well the old ones are). You're going to need very OS specific code for the low level parts of the file system anyway.
- Compression
Not worthwhile. Use a Stacker or JAM driver over the encrypted partition on a PC, for instance. Keep compression and crypto separate utilities... keeps bugs from one interfering with another and reduces complexity of both drivers; also, if one wants crypto w/out compression or compression w/out crypto, no wasted memory (see above about RAM being at a premium).
One of the requirements some earlier posters gave was that they would like to be able to accesss the same data with different OSes (the example was to access the same partition with linux,win95, and winNT). Double space isn't available for unix. (There was a read-only version for linux, but this seems to be currently unmaintained.) So one reason to include a compression module would be for portability of data. I agree with your points about separating concerns and keeping crypto and compression reasonably separate to keep bugs in compression code having the potential to affect crypto code. It would probably be prudent to use OS segment protection, and page locking to protect crypto code and data from being accidentally overwritten, and written to swap respectively.
- Ability to chain algorithms (IDEA and then 3DES for example)
Why? Doesn't necessarily increase security, esp. considering the performance hit (memory... see above, time, key management).
Hmm, say that you were using MDC with md5 as the hash (before Dobertin's recent pronouncements, naturally no one would do this now), if Dobertin comes through with the general case you might wish you had combined it with 3DES... For the paranoid only, but a nice option I think,
[uncontenious stuff]
- Facility for duress key, with the real data hidden in the unused space of the first encrypted drive. To increase the plausible
Huh?!?
Encrypted filesystems are for hiding data from other parties. If your threat model includes law enforcement such a feature would be most useful. You would have data which you would not mind agents obtaining, and have the "real" data hidden in a second file system. When you are supeonaed for your key, you reveal the 1st file systems key. That key does not reveal anything about the 2nd partition, not even it's existance. The second file system would be hidden in the blocks not used with the 1st file system. To access the 2nd file system you would need to tell the file system driver the keys for both file systems -- the 1st key so that it could find which were the unused blocks in the 1st file system, the 2nd key for access to the hidden file system.
deniability all unused blocks within a file system should be filled with garbage, so that it is not possible to tell if there is more data there.
If the algorithm is good, this shouldn't matter. The only way a person could tell if a sector is unused is if that person was able to mount the partition already.
Yes, that's the idea -- your 1st key has been supeoned is the threat model.
- File system steganographically hidden in files on another file system (encrypted or not). Support for a wide selection of file formats (Aiff, Wave, Midi, JPEG, GIF, RGB, MPEG).
Now this is getting nutty!!! Never mind the size,
4 gig disks are cheap these days
compleixty and amazing slowness of such a driver... you'd have to have audio or video files of gigabytes in size to be able to store anything of use.
Indeed you would. So?
- Ability to use stegoed file system in files on an unencrypted file system, and boot from a floppy to access stegoed file system, with no other traces left on hard disk.
Why? The authorities would wonder why you have an 8 Gig JPG on your disk and figure you're using it for stego, or you're crazy, or both, and have you committed.
Nah, you'd buy some video editing equipment, perhaps a photo-CD recorder, start a business doing photo-retouching (I know someone who does this btw, they use DAT tapes just to shift the Gbs they get through), video editing, whatever. All quite plausible. Adam -- only quiche eaters need ritalin...
participants (5)
-
Adam Back -
Deranged Mutant -
Joe Block -
Mark O. Aldrich -
The Deviant