how-to block ads
|
|
Share Topic
 |
 |
|
|
|
1 edit | reply to Blackbird
Re: Idea for steganographic filesystem for Windows 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
 ·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... | |
|
