From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] few questions on truecrypt and luks
Date: Tue, 16 Apr 2013 18:44:05 +0200 [thread overview]
Message-ID: <20130416164405.GA17985@tansi.org> (raw)
In-Reply-To: <1366100818.516d0b524e4cb@www.inmano.com>
On Tue, Apr 16, 2013 at 10:26:58AM +0200, octane indice wrote:
> Responding Arno Wagner <arno@wagner.name> :
> > > > 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@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-16 16:44 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
2013-04-15 22:40 ` Jonas Meurer
2013-04-16 8:26 ` octane indice
2013-04-16 16:44 ` Arno Wagner [this message]
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=20130416164405.GA17985@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.