[Home]SteganographicFileSystem

ec2-3-141-193-158.us-east-2.compute.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

Sufficiently encrypted data is indistinguishable from random data.




Fill a hard disk with random data. Use a key to both encrypt data and find its location on the hard disk. Now, without the key, you can't tell where encrypted data is, or even that there's any there at all.

Have lots of keys. Because there's no way of knowing that there is data stored on the hard disk without the correct key, data will sometimes be overwritten; so make lots of copies of it.

Memorise your keys. Don't write them down anywhere.

Now, when the police call and ask you to surrender your encryption keys under GAK?, you can say - "Secret data? What secret data? Look, here's my key. You can see that all that's encrypted under it is love letters. The rest of the hard disk is filled with garbage." And no court will be able to prove otherwise. At least, in theory.

Perfect for the paranoid freak.

A big point is the ability to have arbitarily many layers to the encryption - you can neither prove that there is more, nor that there is no more data to be found.  Its one of the (many many) things that were proposed primarily to point out how worthless the proposed GAK? law was.  And thus, of course, someone went and created a few implementations.  --Vitenka

A few observations:-
How about, "I've got this embarassing correspondence where I discuss fetishes with my gay lover and I wanted to keep it encrypted so my grandma wouldn't come across it when she uses her grandson's new-fangled typewriting device to go on the interweb; I really don't know much about crypto, and this free software I got from the net because the bloke down the pub said it was good didn't give me a choice about making a stego partition. Here's the key, you can read all about my sordid life if you're *that* desperate. Other keys? What other keys? I only have one computer, one gay lover and one grandma; what would I want other keys for? What, you mean you can have more than one key? Wow, you learn something new every day!
And if the jury believe you're a computer-illiterate that might well work. But if the prosecution can produce a record of your participation in this discussion, or a record you studied computer science at university, or posts made to newsgroups by you about cryptography, or a witness who will testify that you were aware of the concept, they might not be so ready to believe that.
Oh, if you *are* computer-literate, you use "crypto is a hobby of mine", and troll sci.crypt enough to make it plausible. Use the excuse appropriate to your situation, duh! - MoonShadow
And then it's up to the jury to decide whether it's really just a hobby or whether you're trying to set up a 'hobby' as a cover for really nefarious activities, based on the other evidence the prosecution puts before them (eg the guy who testifies that you were talking to him about when the security shift changed at the government building). That's what juries are for, you know.
Indeed. The goal is plausibility, not rock-solid defence. - MoonShadow

That has little to do with the courts though, does it? If they want to get at the data without going through the courts they can just by breaking into your house, copying the disk, and setting their best men onto cracking the encryption. Changes are that they already know some of what they're looking for, too, so they'll be able to tell if they've found it.
Well, it's related to the courts in that a keylogger might be used in the process of gathering evidence that would end up in court.  But the remark was intended as a general comment on hiding the existence of your data: however strong your cryptography your actual security is no better than the weakest link.
Uh - has anyone actually denied that SFS, like any other security technique, shouldn't be seen as a silver bullet - just a component of a system? - MoonShadow

Actually in Britain the judiciary is well-separated from the legistlature, and the courts have a record of being very awkward for the government, so having a watertight defence probably would get you off. It has been suggested that one of the reasons behind the recent constitutional changes (in the Reshuffle of Chaos) was to enable the government to start appointing more amenable judges rather than the ornery lot we have at the moment. In China you might be right, but not here.
You're missing the point.  Look at the approach the British security forces took with the IRA, for instance: death squads and collusion with "friendly" terrorists.  If they really want to "get" you, having a watertight defence will be irrelevant because you won't even be in court.

Nifty. I spent a while trying to work out a variant of this which would allow for successively deeper layers, without actually overwriting anything. Arguably not quite as useful, but if you first add an exponentially distributed number of 'false' layers, before adding the data, I think I managed to construct something which could not be attacked successfully with statistical analysis. The biggest headache was the need for every layer to have access to the keys of the previous layers, in order to manage collisions, and suchlike. It's limiting to impose a rigid layering structure, but you don't run the risk of data loss (reducing this to a given probability could impose huge overheads...) - a pure steganographic system could be used to store the keys, I suspect - with the hashing function taking an 'offset', and new offsets beng tried each time, until all the layers can be accomodated. The offset would have to be stored plaintext, but I don't *think* it would tell you anything about the keys stored - or at least so little as to be negligible. I could probably implement this in a sandbox, given a decent pseudorandom hashing algorithm, and some sort of plausible encryption algorithm. I might well do, if key-escrowal laws ever get implemented. (I'd even store things on it - and then escrow the keys. Lots and lots of keys. For nothing much useful... ) -- TI

Um, I'm probably being stupid here, but how exactly do you prevent overwriting of higher levels by lower ones given that the whole point of the system is to hide the existence of higher-level data from lower levels? - MoonShadow
Indeed. The user must be aware of all of the levels below their own. As it happens, my answer was simply for the higher levels never to write to space 'designated' for lower levels. Those bytes are simply skipped (decryption, similarly, skips layers). Actually, given that, it makes no sense to add 'junk' layers, since the fact that they are junk is easily verifiable, given any 'data' key. It's not a perfect system, by any means - it's just something I was knocking ideas around for, a while ago, independantly of hearing the description above. -- TI

Several approaches are possible.  The easiest is to simply not do so, and to keep multiple redundant copies around.  Then periodically you decrypt looking for those copies and regenerate new copies of anything in danger of being completely trashed.  Other approaches would use known properties of the overlying file system - such as storing the real data in places that the file system will not get to any time soon and hoping the user doesn't run a defrag.  --Vitenka
Um. IIRC, it is possible to estimate activity by an examination of magnetised regions on the disk surface using techniques similar to those described in the introduction to [this] paper (although I cannot seem to come up with a set of Google keywords that will produce the reference I am after without also burying it in a haystack of irrelevancy). So unless you can produce a regular background of activity over the entire disk surface, forensics will be able to estimate how much data you have stored. This would seem to rule out the techniques based on known properties of the overlying file system that you describe, since unless the stego filesystem acts to destroy such properties, they can be used by the courts. - MoonShadow
Perhaps I am guilty of using the layers approach too much - but I would have assumed that the physical properties were a seperate concern.  The obvious thing to do is to accompany every steganographic operation with a write to a random large number of blocks. --Vitenka
You don't actually have to, if your real writes are to random locations in the first place. But the technique for not overwriting stegoed files that you mention above, the one that relies on knowing where the filesystems of stego levels you can't see at the time you are writing are going to put things, would generate nonrandom writes. - MoonShadow
  I was also assuming that the stegged data was rarely accessed and thus wouldn't show up.  --Vitenka
Eh? MoonShadow doesn't understand.
The physical level analysis doesn't have a fine enough level of detail to differentiate a block of data which has been accessed once (when the disc was formatted) from one which was accessed twice - though it can easily tell if a block has been accessed a whole load of times.  So a block of steg data is very hard to tell from a block of unaccessed data this way, if that data is accessed only rarely.  --Vitenka
Surely if this is true, all the people overwriting their data multiple times have nothing to worry about? OTOH, if you can indeed read previously existing blocks, as the paper linked above and other similar ones around would imply, you can tell when a block has been changed just once. - MoonShadow
As I understand it, the technique works very well for showing the previous contents of a block that has been overwritten once and had a set of previous data on it for a very long time.  It's far less effective if the new data has been present for a long time, or if the block has been overwritten many times - but it is very good at telling if this is the case.  But none of this really matters - they can read all of the old steg data that they like, it's still intended to be incomprehensible random data.  --Vitenka

Alternatively, just run a stego version of defrag periodically, which reshuffles every block on the disk and thus hides your data access patterns.  --Vitenka
If it shuffles every block on the disk, surely it loses all data in levels you can't see at the time you run it? - MoonShadow
Not if it literally shuffles - preserving all data regardless of whether it is marked as good or not (You'd lose the 'what block is where' tables, but those can be recreated).  But I meant that this operation would be performed as an operation of the steg aware filesystem.  --Vitenka

ISTR the main purpose of these multilevel filesystems was to demonstrate the stupidity of the RIPA? legislation - its wording was pathetically easy to defeat.  Obviously, a government can step outside of the bounds of its laws - but they can't do that too often, for too minor an offence.  --Vitenka

Who needs RIPA?, anyway? These days the very presence of crypto software on your machine is [evidence of criminal intent].. (well, not really a fair description of the decision - SlashDot? hype - but an interesting precedent nevertheless) -MoonShadow



CategoryComputing
See also Crypto, Pontifex.
Not to be confused with Stegosaurus.
Or [Steg].

ec2-3-141-193-158.us-east-2.compute.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic
This page is read-only | View other revisions | Recently used referrers
Last edited May 25, 2005 9:21 am (viewing revision 32, which is the newest) (diff)
Search: