On Mon, Sep 14, 2009 at 09:28:21AM +0200, Rick Moritz wrote: > A solution to this issue may be the option to load an external LUKS header. > This could be on an encrypted USB device and therefore not trivially linked > to the actual disk. The option, if not there already, could also aid with > some troubleshooting or backup procedures. I like this idea. It could basically be a commandline option giving a file that contains the header and keyslots. There would also be need for an option to write this information to file, something people have been asking for anyways for backup purposes. Add an option that allows selectiion between ignoring a header and assuming there is no header, and the backup issue is silved at the same time. > On the other hand plausible deniability is extremely hard, and requires > security measures beyond the dimensions of user friendliness. Indeed. > Therefore > losing the LUKS feature-set should be a least concern. Using a > steganographic approach is more suitable, especially when large amounts of > encrypted, apparently scientificallly used data are used as background noise > - inserting some small amount of hidden extra information into that should > be quite hard to detect, if the system is properly designed not to log > "incriminating" operations on mounts that are supposed to contain other > data. It may be better to hide the encryption on the first place and go the steganographic way completely. > The problem with encryption is that you mostly need to do it properly in > order for it to work - LUKS is by design not the proper way to do plausible > deniability, and the penalties incurred are not reasonably overcome. Without > steganographic approaches plausible deniability should not be considered to > be realistically achievable. Or worth anything, see my last post. > And even then it may not work out. > Plain dm-crypt is the way to if you expect your attacker to be lazy and and > not very creative - believing that you're keeping disks full of not very > random data is in many scenarios unlikely. Actually, the "not very random" property is about as difficult to see as breaking the encryption. Encrypted data looks very random. You could, for example, carry around several files with high-quality noise (run it through a crypto-hash for better properties) and one among them is actually your encrypted data file. Distinguishing the file type is about as hard as breaking the encryption. > I'd like to point to my first line again though: Is it possible to load an > external LUKS header? This may be an approach to superficially adress the > original issue. Not at the moment. There is a note in the LUKS on-disk format document I believe, that states that backup and restore of headers is planned. Arno > On Mon, Sep 14, 2009 at 5:32 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > > > On Sun, Sep 13, 2009 at 09:44:31PM +0200, Ivan Stankovic wrote: > > > On Sun, Sep 13, 2009 at 08:36:02PM +0200, Arno Wagner wrote: > > > > > One thing I'd like to address however, regarding a possible future > > > > > implementation of truecrypt-style "hidden devices". If you'll ever > > plan > > > > > to do such a thing, remember that they are absolutely useless (except > > > > > maybe for USB sticks) until it will be not possible to use something > > > > > different from FAT16 for the host device. I tell you this because I > > had > > > > > many, many difficulties using a hidden device for my home, until at > > last > > > > > I had to abandon the idea. > > > > > > > > It is basically not possible to have a hidden volume or any hidden > > > > datya without raising suspicion. The entropy of the encryoted data > > > > cannopt be hidden and some seemingly random data will always be > > > > presend in the presence of a hidden volume. You can only claim > > > > that this data is not a hidden volume, and you can do the same > > > > already with a plain dm-crypt device. > > > > > > ... but not with LUKS. And this is what I'm looking for: having > > > all the benefits and convenience of LUKS but without the revealing > > > signature. Making sure that other components of the system do well > > > with respect to deniability is, of course, the user's problem. > > > > Basically, you cannot get this with LUKS. You would need to give > > up all plausibility checking, for one thing. That would change > > the characteristics too much. I think you should stop trying > > to fit a round peg into a square hole. LUKS was never designed > > to hide. > > > > Of course, if you are really desperate to do this against all > > advice, you are always welcome to fork... > > > > Arno > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > > arno@xxxxxxxxxxx > > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 > > 338F > > ---- > > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans > > > > If it's in the news, don't worry about it. The very definition of > > "news" is "something that hardly ever happens." -- Bruce Schneier > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > > -- > Rick rocks. > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
