 BlackbirdBuilt for SpeedPremium
join:2005-01-14
Fort Wayne, IN
kudos:2
 ·Frontier Communi..
| reply to jansson_mark
Re: Idea for steganographic filesystem for Windows Some added thoughts on all this. Steganography is, in and of itself, not inherently a typical encryption process. It is actually an obscuration process. All it basically attempts to do is to hide a plaintext string (or whatever) within a relatively complex data field, be that a written message, a visual image, "normal" mathematical tables, computer files, etc. What it offers, if performed properly, is a highly-undetectable "envelope" carrier for whatever information is embedded within. But the key to a typical successful steganograph is for it to remain covert. That is, its role as a carrier of information within must remain undetected.
In actual practice, the steganography realm often blurs and merges into the encryption realm. Rather than simply embed plaintext characters (or digital representations thereof) directly into the carrier data, one or more encryption-like processes are additionally employed to protect the plaintext even should the steganograph be detected as such. That encryption can be conventional upon the plaintext, with direct embedment of the encipherment into the carrier. Or it can be integral to the steganographic process - i.e. the use of pseudo-random placement of the next plaintext character within the carrier data or the use of pseudo-random rotation of placing that next character between one of several carrier data objects or files.
Typically, top-notch steganography will do both. That is, it will first conventionally encrypt the plaintext into encipherment, then integrally super-encrypt that cipher text pseudo-randomly into multiple, similar data objects or files. Decryption then requires all the steganographs plus the baseline, along with the algorithm seeds for the stegano-encipherment and for the basic encipherment. The advantage is that, unless someone slips up procedurally, every element of the process stands alone as completely undetectable in being a carrier for the steganographed data. Retrieval simply means accessing all the steganographs, knowing the seeds, and reversing the process... a rather easy task for covertly and securely communicating plaintext to whomever. Especially if the carrier steganographs are posted on separate, ordinary-looking websites and the baseline is an "ordinary" data object present on all the players' computers. Typically, the only risk is data corruption of any of the carrier files themselves along the way - unless somebody is "looking down from above" to monitor which files are moving where all over the Internet and is able to detect and recognize the activity as steganographic... then they still have to crack it and any underlying encipherment.
There are all sorts of variations on these principles. One can use a widely-held, invarient baseline object/file and have a separate listing of which baseline characters represent the next character of the plaintext stream... that is, an Ottendorf cipher. But that means the key is the character-location listing, and it must be undetectably stored or conveyed to a recipient. This is not that easy, since it so clearly appears to be what it is: a key. Detection of the key means the analyst then has to either determine what is the widely-held baseline object or else directly attack the Ottendorf key's listing - which, unless superencipherment was employed, does readily lend itself to language-frequency cracking.
Or one can use an invarient baseline data pattern held securely by the author (and recipient, if any) and create slightly-offset clones whose offset patterns themselves convey the underlying plaintext... that is, ordinarily-understood steganographs. That means the baseline must be securely stored and the encipherment product must be undetectably stored or conveyed - which is remarkably easy if the baseline and carrier are each a fairly complex graphics image, music file, or video whose minor alteration remains undetectable by normal viewing means.
In your process, the hard drive itself becomes the steganographic carrier. Location of the critical clusters is the steganographic algorithm, and the removable-media-based software is the 'key'. Strong data encryption (TC-like) would also likely be applied to the critical data before embedment to obtain a super-encryption effect. Ordinarily, that would be sufficient to avoid detection. However, if the "key" must leave behind predictable tell-tale processes, files, or tables to govern the OS or disk utilities in preventing corruption of the encipherment, then such tell-tales become readily-detected vectors to the presence of the steganograph. Once detected, a single steganograph is no more secure than any other encipherment technique... which is why multiple steganographs are sometimes used with image steganography - successful cracking would require all the steganographs together. But to not leave the tell-tale behind to continue governing disk writes would risk the corrupting effects of the OS and/or disk utilities over-writing or relocating the critical clusters... and corrupted encipherment means unretrievable plaintext.
--
If God wanted us to work with electrons, He'd make them big enough to see... |
