On Tue, Apr 16, 2013 at 10:26:58AM +0200, octane indice wrote: > Responding Arno Wagner <arno@xxxxxxxxxxx> : > > > > 3. luks doesnt support hidden volumes. > > > > > > > It does, in a way. > > > > True. Not much worse than the TrueCrypt variant actually. > > > > > The problem with hidden volumes is this: Either you have > > the risk of destroying them, or you cannot use the > > partition they are hiding in (which gives a good hint to an > > attacker), or you need to reserve space for them > > explicitely (which gives a strong hint to the attacker). > > > > TrueCrypt does not do any better here. > > Truecrypt helps here: > If you know both password (normal + hidden) container, > you have a mode where you can't overwrite your > hidden datas, it helps for safety of hidden datas. Not really. Forst, it returns an error on write access to the hidden container. That is bound to leave filesystem annomalies and possibly even log-entries. Second, as it returns an error, reliable use of the outer container is not possible anymore. I am not criticizing TrueCrupt here, this seems to be the best that can be done in the given situation, but "the best" is not really good. > >Also keep in mind that in many situations (US border > > inspection, e.g.) the mere suspicion of a hidden > > partition being present will be enough. > > > But with truecrypt you can only have at most > two partitions: a normal one, and a hidden one. > So, if you're really in big trouble you can > tell the two password, proving that there is > not anymore hidden data. This would assume the poeple that you have trouble with actually understand the technology. If they keep insisting you show them "the hidden partition" that "TrueCrypt always creates", what are you going to do? > With cryptsetup method, you can have > unlimited hidden parts, leading to > unlimited suspicions, no matter how many > password you give. But that it is even possible with cryptsetup is already advanced knowledge, while with TrueCrypt it is an openly advertized feature. > Don't know which is worse. Depends. What plain dm-crypt can do is something you can do with any headerless encrypted format. The only real protection (once _competent_ forensics people are looking at your set-up), is to provably have no secret data. That means once you open the container for them, all unused space is zeros or at least low entropy. AFAIK TrueCrypt blanks with crypto-randomness, i.e. that approach is out. Plain dm-crypt/LUKS do not blank at all, which is not really better. Unless you overwrite the opened container youself with zeros, you cannot prove the absence of data. But this is a huge effort as it has to be re-done basically whenever a file is deleted or overwritten. _And_ the typical recomendation for secure deletion is still overwrite with crypto-randomness. Bottom line is that you are only safe if you do not have an encrypted container when going into a situation where suspicion could fall on you. The best approach is not to carry encrypted data, but to go over borders, etc. clean and then transfer via the Internet, possibly using some free wireless and a server on the other side that is not easily associated with you. Before you go over the border again, at least do a secure erase or destroy the disk and leave it behind. It is a shame that non-criminals even have to think about this. But some parts of law-enforcement to not want you to have privacy, hence encryption is still viewed as a "terrorist" technology, ignoring the legitimacy of, e.g., personal stuff and trade secrets. In countries with a working legal system there will eventually be court decisions that the presence of high-entropy data is not enough to support the claim that it may be encrypted data. But before that happens, anything looking encrypted is a potential problem. (There are a number of legitimate reasons other than encrypted data why that high-entropy data could be there. For example, I do experiments with true-random number generators and after whitening the result is indistinguishable from encrypted data. Yet I store the results for analysis and they can be large. I also wipe disks securely by mapping them in dm-crypt with a long random key and overwriting the mapped container with zeros. No way for me to prove they were erased.) Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
