I do not mean to undertake your idea, but I got this simple question that your design does not solve:
What's next when you get caught? The whole point of your system is protection of data for the user if the CD falls into other hands. But the legal context nowadays requires you to give the key. - With your system on my livecd, legally I can get in Europe 2 years and a huge fine if I keep my password secret, hence I will handle the key to get something under those 2 years, and every one would do so even you, I guess. Your design is like writing on that CD that it is encrypted: the first guy who boots it finds out that you have something to hide! So at the end, the whole design of such system falls into pieces. I mean, it's alright for the university, your friends but it is simply not enough against legal constraints which is my main concern, let's face the worst enemy, cryptography simply fails to protect valuable information because of yourself: be realistic, will you just keep your mouth shut when that legal voice will trade:"give us the password or it's 2 years!"? - With my system on my livecd, the overall clear side is part of the stealth concept, keep it as usual as you can from the outside, the less change the better. Then I just copy my binary to something irrelevant into /usr/bin and my container file somewhere in /usr/lib and here we go. From a forensic perspective analysis it is much more difficult to reveal the encrypted material. You got in the first place to actually find the encrypted material(few bytes over a Gigabytes). How can charges be pressed without evidence? Then when evidence is found as a file, you have several containers to fall back to. You give a first and single password away that will decrypt a different part than the one you are protecting. Finally, the comparison with true-crypt is unfair (for true-crypt) because it can handle up to 2 containers inside of each other, as denyfs goes up to 16 containers, along with 16 != passwords . It's programmed so, but again the setup has to take that 15% data ratio in account or you will start messing with statistic which is your worst enemy. Truecrypt does not deal with this issue and will never, because math cannot solve this problem. The probability of collision increase exponentially with the number of containers along with the size of the main container. And yes denyfs one so often breaks, by overwriting some bits here or there, let's say 1/10 but this is the reason why it makes it so powerful and no reversible. At the end it is a human choice, the user defines a trade between the size of his main container and the number of sub containers he will create to fit the specific amount of data that needs hiding. And this is the missing parameter in the problem, hence the reason no such perfect system will ever be implemented. If you have containers A and B that do not know their respective existences, how can you ensure they won't overwrite bit of one another? You simply can't! You fall into statistics and the only choice to optimize integrity is to up size a huge main container and work on say 5% max of the whole size. Add to that, that 5% rate needs to be lower each time as you create sub containers. Cryptography is an open door to investigation, the first question is:"wtf does he want to hide?" If you can evade this reflexion in your "opponent" mind then it is then very highly probable that the material that needs to be hidden will stay hidden! That's the key concept of military data flow over enemy lines (sounds heavy but true) nowadays in military IT mainly inspired by an Oxford professor (the one who wrote the first public implementation forked on ext2 called StegFS, he's easy to find). The point is to evade torture (physical and psychological) of messengers when they get caught with encrypted data. anyway I made my point that the "best" technology for such job exists and is available and it does *not* apply your design but something much more subtle. Good work for your stuff, it's good for countries which do not have yet IT laws like the one mentioned, Africa, South America (except Brazil) and I'm sure a couple of penguins in the North pole but for European and US citizens, this kind of protection has no legal dimension, and will fall into piece in a real governmental situation. I'm looking forward to a merge into the official catalyst project. Thanks for reading. On 7/1/07, Nelson Batalha <[EMAIL PROTECTED]> wrote:
I would like to quote these two statements: http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS#Two_things_to_remember Thanks for your help, but: > It does not protect more the user while he uses it nor from > potential "after-use" trails. So? Was I supposed to release a complete secure solution right now? :P > Either you lose the livecd > along with your identity (or data that leads to your identity) and > you get caught or while using the software you get caught (like > your TOR connections have been detected). The only purpose and > advantage encryption would have is to > obfuscate some passwords like in the firefox example you gave. The idea is that with this livecd you're on the move, boot the cd, use tor and go away asap once finished. Make sure all your sensible data is sent in a package just before leaving. If you lose it or someone looks at it, it won't suspect much. > The real solution to your problem would be to use a steganographic > layer ( http://en.wikipedia.org/wiki/Steganography[1] ) . It's not like I didn't remembered steganography, read below. > You will not find much (I mean actual real software) besides some > linux-2.2 tweak over ext2 "proof-of-concept" (10years old > not stable unreliable) False? Look for TrueCrypt. > I think that encryption has nothing to do with hiding. In the > contrary, it is like a big flag standing saying "hey look at > me I got something to hide, come and get me!". It is just > obfuscating technology. Using the crypt_silent option how likely are you of being catched? Just put some binaries of emacs and so on on the root, and demonstrate in the fake root that's what is for. It is a good hiding technique I think, but not perfect. The thing is, given the low probability of being catched, either by having the squashfs with Steganography or not, some large file would be there, and if they're good enough to realize it is a bootable livecd and it is forcing a fake boot, then they're good enough to see a big closed file is there. Unless one did multiple hidden volumes inside this one, or just hide some files inside the root. But we're back to less usability and we're being forced to use truecrypt (I don't see a currently free maintained option). If we accept the Truecrypt restrictions (haven't read everything, but it's not gpl so I assume they're more restrictive :P), we could implement these several layers of encryption and increase functionality with some scripts hidden in a pen for example. But to put any programs like firefox+torplugin+tor+privoxy in them, and separate in small files, that's a lot of work. This implementation is good enough for most cases. Also Luks is well maintained and GPL. > Now, from a legal point of view, being caught with an encrypted > material whether livecd or not in major countries > (UK,GER,FR,US,china) requires from you the decryption key Fine for me, don't do anything illegal in free countries. As for the China example, just do as on my second point and use the following idea: encrypt with luks as it is, and for the more sensitive files you can use stenography using stenography software in a separate volume (like a usb pen). If they ask you for the key, give it to them and show just some more innocent files you were hiding. It's better then have the cd almost all open, again, because you may lose it. Let me know if I'm wrong or if you have more ideas ;) Cheers, Nelson -- [EMAIL PROTECTED] mailing list
