how-to block ads
|
|
Share Topic
 |
 |
|
|
|
 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 The primary object with any encryption system is to avoid presenting any information to those who might attempt hostile access... and that information includes the mere existence of encrypted info, the location/size of such, the technique used for the encryption, details of the language/content-type/data-structure of the plaintext, etc, etc.
In a computer environment, that implies both the encryption scheme used and the specific product created should not only hide their existence from casual (or even determined) browsing, they must also hide their existence from those who would attempt to expertly search for them on the basis of known/published rules, protocols, or patterns for laying down encrypted documents - regardless of how those embedment technique might work. Right off, that means the software used to create and embed the encryption must, itself, not ordinarily reside on the same system as the encrypted material, else a direct vector is created to cue the analyst onto how best to seek out encrypted products related to that software. And the encrypted material must not self-betray its existence. An amazing number of digitally-encrypted documents have been speedily cracked, simply by recognizing the kind of software that created them and focusing on the encryption attributes unique to such software... and that revelation came from simply viewing the encryption software resident on the same computer or by studying header information in an obviously encrypted file.
The foundational problem I see with your creative concept of using the hard drive as a container is that there must be something hosted on the system that prevents Windows or any other OS from over-writing any sectors/segments/clusters used by the encryption scheme. And that, unfortunately, provides a vector identifying that the drive may be encrypted and what the encryption techniques may be. Once that is known, all the analysts' horsepower can be leveraged into cracking that specific system. Another potential problem is that many kinds of disk cleanup programs (defragmentation, repair, etc) move data around with abandon... unless use of these were blocked or governed by the encryption program's "something", havoc would result with the enciphered text which would render the plaintext unrecoverable. And, of course, existence of that "something" would again point directly toward the presence of encrypted material and the technique used to create it.
Part of the difficulty resides squarely in the nature of what one is attempting to encrypt. The smaller the plaintext core, the better and safer things will be. The larger the plaintext body or number of files being encrypted, the harder it is to hide the presence of the encipherment and the harder it is to prevent cracking once detected. In general, if one is attempting to encrypt folders full of numerous files, the results of whatever is used will be measurably less secure than similarly encrypting a short segment of plaintext using the same techniques.
Some of the very best steganographic encryption for simple data/text occurs by differential offset patterns between two or more large, seemingly-identical data files whose content is manipulated at the LSB level to produce low-level difference information between the files. Images, videos, or music files are splendid for this purpose because of the ability of the data bytes to withstand careful manipulation without inherently corrupting the "cover" nature of the file. For example, by shifting the LSB of a pseudo-random sequence of some of the pixels within a large image of the canals of Venice produces an effect that is invisible to the naked eye when viewing the image as a simple graphic. At the same time, unless one has the exact original baseline image for direct comparison, it is impossible to tell that the file has been manipulated or that any encrypted information is contained. And, by using multiple, offset-image encryption files to jointly carry the overall encryption, one can use a rotating scheme of encipherment between the images that makes it impossible for hostile reconstruction to occur unless all the enciphered images plus the baseline are collected together, along with the unique pseudo-random pattern used for the rotation amongst the specific files on a bit-by-bit basis. There are an almost infinite variety of such steganographic encryption variations that can be conceived (and implemented)... making detection and cracking almost inconceivable without a-priori knowledge of the encryption specifics. Because the host files are passive, there is no attention-drawing vector that points to their existence as anything worthy of special attention... especially if they reside in different locations, some being online at different sites or on separate pieces of removable storage media.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
1 edit | said by Blackbird:Right off, that means the software used to create and embed the encryption must, itself, not ordinarily reside on the same system as the encrypted material, else a direct vector is created to cue the analyst onto how best to seek out encrypted products related to that software. And the encrypted material must not self-betray its existence. Well, thats what I had in mind too...program could be for example named to something else and carried with you in USB-hdd etc...then with a touch of button it would dismount all volumes, wipe its program files and (after uninstalling it first) driver and clean the registry from its existance. From my post at Truecrypt forum:
quote:
1a) Create "traveller version" that automatically, once launched, disables "recent documents" from working so that no information about files launched from the encrypted volume will remain. Ofcourse programs like Word still keep list from files being opened so maybe users should use CCleaner too but anyway...
1b) And, once TC is exited, deletes the registry keys and driver from the hdd.
1c) And also has capability to read-only-mode for containers/drives if user is working only with user level permissions.
--
My computer security & privacy related homepage »www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. | | |
|
BlackbirdBuilt for SpeedPremium
join:2005-01-14
Fort Wayne, IN
kudos:2 Reviews:
·Frontier Communi..
| said by jansson_mark: ...program could be for example named to something else and carried with you in USB-hdd etc...then with a touch of button it would dismount all volumes, wipe its program files and (after uninstalling it first) driver and clean the registry from its existance. From my post at Truecrypt forum: quote:
1a) Create "traveller version" that automatically, once launched, disables "recent documents" from working so that no information about files launched from the encrypted volume will remain. Ofcourse programs like Word still keep list from files being opened so maybe users should use CCleaner too but anyway...
1b) And, once TC is exited, deletes the registry keys and driver from the hdd.
1c) And also has capability to read-only-mode for containers/drives if user is working only with user level permissions.
Unfortunately, that still leaves some kind of control or housekeeping program resident on the encrypted drive to govern the OS's use of encryption-intended drive sectors. That will still betray the presence of the encryption methodology in use. Unless, of course, one doesn't use such a resident control program and simply takes the chance that the OS or a disk utility won't "puppy-track" all over even a few of the encrypted sector elements. Because if that happens, the plaintext beneath will be toast.
Obviously, if the inherent encryption algorithm is strong enough, it should nevertheless withstand a lot of attack even should its presence get betrayed. But still... an undetected encipherment is an unbroken encipherment, no matter what power the analysts' tools possess.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
| quote:
That will still betray the presence of the encryption methodology in use. Unless, of course, one doesn't use such a resident control program and simply takes the chance that the OS or a disk utility won't "puppy-track" all over even a few of the encrypted sector elements. Because if that happens, the plaintext beneath will be toast.
I explained in my post to Truecrypt forums, that since Windows generally writes to the first available sectors on the hdd, there is very little actual risk of encrypted sectors getting hammered if they are in the area that is near at the end of the hdd.
Ofcourse, one could use this kind of encryption only on secondary partitions or hdd:s, where one would not normally write any (other files)...sure they might be some files present there to "explain" the hdd:s existance, but user would be carefull not to add much more onto the hdd.
Also, if user wants to add files the the hdd/partition where "superhidden" container is, one could simply first MOUNT the "superhidden" container and let the TC protect those sectors from Windows overwriting. Then you could write anything you like in that hdd/partition or inside the "superhidden" container without any fear that container would be overwritten.
--
My computer security & privacy related homepage »www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. | |
BlackbirdBuilt for SpeedPremium
join:2005-01-14
Fort Wayne, IN
kudos:2 Reviews:
·Frontier Communi..
| said by jansson_mark: I explained in my post to Truecrypt forums, that since Windows generally writes to the first available sectors on the hdd, there is very little actual risk of encrypted sectors getting hammered if they are in the area that is near at the end of the hdd. ... Also, if user wants to add files the the hdd/partition where "superhidden" container is, one could simply first MOUNT the "superhidden" container and let the TC protect those sectors from Windows overwriting. Then you could write anything you like in that hdd/partition or inside the "superhidden" container without any fear that container would be overwritten. Depending on the "value" of the encrypted material, I'm not sure if I'd want to simply trust to Windows "generally" doing anything. Normally, if it's needful to encrypt something, it means it's high-value material in the first place... and not something you'd want to risk to the whims of Windows' "typical" but unspecified behavior. And there's still the issue of certain disk utilities - especially defragmenters - that may routinely shift certain file-types or even ordinary ones to the end of their partitions in order to collect enough contiguous partition free space to "do their thing".
The mounting concept might help with the Windows over-write risks, though you'd have to keep the superhidden container mounted at all normal-usage times, then remove all traces completely when you wanted the drive encryption to become covert - and hope that nothing Windows subsequently did while in that state would cause harm to the encryption sectors. But 'mounting' would probably run afoul of certain disk utilities, many of which need the computer environment to be simple and basic, with all other material "turned off" or unmounted before running... and that's the very thing you wouldn't want if the utilities should happen to habitually shuffle the encrypted partition's cluster deck in order to do their job.
Whatever encryption scheme were used, along the lines you've described, it must be strongly covert and randomized with regard to its nominal starting-point sector usage and the general layout of subsequent encrypted locales. If such a scheme were deployed, it's a sure thing that the expert analysts would become immediately aware of it and routinely check any target drives for characteristic usage patterns or attributes of end-of-drive bit-pattern placement that might yield to machine analysis to betray the presence and nature of the overall encryption technique used. Once that cat was out of the bag, the heavy-duty cracking focused on the specific discovered encryption technique would begin.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
davePremium,MVM
join:2000-05-04
not in ohio
kudos:7 Reviews:
 ·Verizon FiOS
·Verizon Online DSL
| reply to Blackbird
The approach taken in StegFS seems to be to create enough redundancy (i.e., extra copies of data) such that you can stand to lose a lot of it.
»www.cl.cam.ac.uk/~mgk25/ih99-stegfs.pdf | |
BlackbirdBuilt for SpeedPremium
join:2005-01-14
Fort Wayne, IN
kudos:2 Reviews:
·Frontier Communi..
| StegFS does contain some interesting concepts, and the redundancy scheme indeed represents a more than passable attempt to deal with over-write corruption issues. But, at least in the form described, StegFS leaves footprints betraying its presence, either via its files or via the recompiled kernel needed to support it (unless one uninstalls its files completely and also reinstalls the original UNIX kernel, trusting the encrypted drive fragments totally to the not-so-gentle ministrations of OS over-writes). I'm also wondering how rapidly the scheme's attributes deteriorate as the disk/partition fills more and more with normal files - especially the overwriting percentage vs. redundancy-level measurements they describe.
The idea of "plausible deniability" put forth by the authors may carry some merit in kinder, gentler locales... but I'd not want to face the consequences of being found to be using StegFS in other, far harsher political climes. Some adversaries will assume the worst and work backward from that, only as one proves himself less than fully guilty. So for such an environment, plausible deniability becomes plausible culpability to the maximum possible software capability. And, given that analysts can read as well as you or I, they'd be quite aware of what maximum security levels StegFS was capable of. In that case, God help the accused user who only made actual use of 2 or 3 of the security levels - how could he ever prove there was nothing at level 15? Obviously, a lot depends on what one is trying to protect, where that occurs, and what the local consequences of compromise or even use-detection might be.
In the blackest of worlds, I'd never trust a steganographic system that left any externally-perceivable footprints, especially adjacent to or internal to the enciphered material... I'd want the steganographs to be stand-alone, with no compromising details anywhere in sight - preferably located on distant website(s) to give me some maneuvering space and time. I guess "hidden in plain view - somewhere else" has some elemental appeal. But many folks' needs can certainly vary widely from that...
I was frankly surprised that the processing "hit" for StegFS was only 6-200:1 for various operations... I'd have expected something so complex and in some ways so elegant to slow things down much more than that.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
|
