On the other hand plausible deniability is extremely hard, and requires security measures beyond the dimensions of user friendliness. 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.
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. 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.
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.
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:Basically, you cannot get this with LUKS. You would need to give
> 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.
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
_______________________________________________
--
Rick rocks.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
