From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] few questions on truecrypt and luks
Date: Mon, 15 Apr 2013 16:59:52 +0200 [thread overview]
Message-ID: <20130415145952.GA30994@tansi.org> (raw)
In-Reply-To: <1366033658.516c04fa751b1@www.inmano.com>
On Mon, Apr 15, 2013 at 03:47:38PM +0200, octane indice wrote:
> Responding to ".. ink .." <mhogomchungu@gmail.com> :
>
> > Two differences i can think of are:
> > 3. luks doesnt support hidden volumes.
> >
> It does, in a way.
True. Not much worse than the TrueCrypt variant actually.
> Create a loop file (or an existing partition).
> fill it with random data (important!)
> cryptsetup luksFormat it
> cryptsetup luksOpen it
> Format the crypted device with FAT32 (important!)
Yes, as FAT32 fills a volume from the beginning.
> Then, use loop with a high offset, e.g. more than half of the disk,
> create a plain cryptsetup
To avoid metadata.
> losetup -o 10000000 device
> cryptsetup create loop secretname
> format it with any filesystem, copy your very secret documents in it, close
> this partition.
>
> By doing this, anyone without the knowledge of the offset + the password
> won't be able to prove that you have datas hidden.
> Warning, if you write more data in the first luks device than the offset
> choosen, you destroy data (but in some case, you may want it).
>
> My 2 cents.
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. 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.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
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
next prev parent reply other threads:[~2013-04-15 14:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 21:39 [dm-crypt] few questions on truecrypt and luks .. ink ..
2013-04-14 8:40 ` Milan Broz
2013-04-14 16:56 ` .. ink ..
2013-04-14 17:32 ` Milan Broz
2013-04-14 17:48 ` .. ink ..
2013-04-14 19:25 ` Milan Broz
2013-04-14 23:19 ` .. ink ..
2013-04-14 16:50 ` Arno Wagner
2013-04-14 18:48 ` Milan Broz
2013-04-14 20:23 ` Arno Wagner
2013-04-15 13:47 ` octane indice
2013-04-15 14:59 ` Arno Wagner [this message]
2013-04-15 22:40 ` Jonas Meurer
2013-04-16 8:26 ` octane indice
2013-04-16 16:44 ` Arno Wagner
2013-04-16 18:27 ` .. ink ..
2013-04-16 22:44 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130415145952.GA30994@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.