[dm-crypt] few questions on truecrypt and luks

[dm-crypt] few questions on truecrypt and luks

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

section 2.2 of FAQ talks of differences btw plain and luks volumes.It would
be nice if the FAQ would also talk of differences btw luks and truecrypt
since cryptsetup now supports truecrypt volumes.

Two differences i can think of are:
1. truecrypt volume header is hidden while luks volume header is open.
2. luks can use upto 8 keys while truecrypt only uses one.
3. luks doesnt support hidden volumes.
Is there any other? cryptographically,plain volumes seem to be weaker
compared to luks volumes.what about luks compared to truecrypt?

since truecrypt also uses a header,assuming the same use cases and with the
same number of users,will truecrypt volume's header be corrupted at the
same rate luks headers will?

Also,cryptsetup 1.6.0 added supported for opening of truecrypt volumes but
nothing is currently mentioned on adding support for creating of truecrypt
volumes.Is the support planned at some point in the future?

[-- Attachment #2: Type: text/html, Size: 980 bytes --]

Re: [dm-crypt] few questions on truecrypt and luks

[Milan Broz]

On 13.4.2013 23:39, .. ink .. wrote:
> 
> section 2.2 of FAQ talks of differences btw plain and luks volumes.It
> would be nice if the FAQ would also talk of differences btw luks and
> truecrypt since cryptsetup now supports truecrypt volumes.

Arno can perhaps add something more to FAQ but I already promised some
talk about truecrypt support in cryptsetup so I have to prepare
more information and comparison, all this will be public, somewhere...

(FYI I am no longer paid for cryptsetup work so my voluntary time
for project is now quite limited now - anyway it means there will be
better schedule plan, just gimme few weeks to settle)

> Two differences i can think of are: 1. truecrypt volume header is
> hidden while luks volume header is open. 2. luks can use upto 8 keys
> while truecrypt only uses one. 3. luks doesnt support hidden
> volumes. Is there any other?

A lot of, but many of them are Win only (backup header, hidden
disk + OS, own boot loader ...) But I will not write Truecrypt
advertisment here, read doc :)

But it uses different architecture (cryptsetup is low level tool,
most of features are expected to be build on top of it).

> cryptographically,plain volumes seem to
> be weaker compared to luks volumes.what about luks compared to
> truecrypt?

No, plain volumes are not generally weaker. It depends how is key
generated - e.g. if it is derived from weak passphrase or it is
generated by good RNG (key in keyfile).
Anyway, it is described in FAQ.

> since truecrypt also uses a header,assuming the same use cases and
> with the same number of users,will truecrypt volume's header be
> corrupted at the same rate luks headers will?

Not exactly the same, because there is a backup header.
But because backup header is located near the end of device,
it adds different problems with device resize.
Backup header is double-edged sword (both from security and
code maintenance POV).

Cryptsetup can use backup header, but you need to say this explicitly
with parameter. There is no autorecovery (cryptsetup will never
touch Truecrypt header - all operations are read-only, at least for now.)

(For me, lessons learned from LVM metadata recovery problems,
it can be done properly and reliably but it is against KISS principle:-)


In any case - if anyone using cryptsetup tcrypt commands - please
report problems and bugs found.
Also successful stories welcomed - actually I have no idea if anyone
using it already and feedback (even completely anonymous and possibly
negative) is very important. Thanks.


> Also,cryptsetup 1.6.0 added supported for opening of truecrypt
> volumes but nothing is currently mentioned on adding support for
> creating of truecrypt volumes.Is the support planned at some point in
> the future?

It depends. It can be done in future.
But the real reasons I did not implement it (except lack of time):

- I want to see real users (of already formatted device) before investing
time to any foreign format or key change operation

- I do not want to cannibalise LUKS which is now de facto standard for Linux
FDE, Truecrypt format support was meant to simplify easy data sharing
with other OS-encrypted disks (without need to instal 3rd party sw),
not full replacement (and there is tcplay already).
Implementing is just part of it, there must be some support to
stabilise it, fix user problems, create knowledge base...

(BTW if anyone have open documentation for other FDE systems, like Bitlocker
or Endpoint encryption, let me know please... :)

- It was experiment if userspace kernel crypto API is usable for this kind
of application, also it was kind of research for older truecrypt header
format and features.

Thanks,
Milan

Re: [dm-crypt] few questions on truecrypt and luks

[Arno Wagner]

Hi,

first I should say that the FAQ is sadly out of date with regard
to anything TrueCrypt, as I wrote most of it well before 
TrueCryupt support was added. Feel free to point out anything
that needs adjustment, I will eventually find the time to do it ;-)

It should also be said that TrueCrypt format is an "alien" 
option, in my view primarily for secure data-sharing with
Windows. (Milan: If the strategic intention is different,
please correct me.) As such, a full comparison or representation
as primary format option is probably not a good idea.

On Sat, Apr 13, 2013 at 05:39:00PM -0400, .. ink .. wrote:
> section 2.2 of FAQ talks of differences btw plain and luks volumes.It would
> be nice if the FAQ would also talk of differences btw luks and truecrypt
> since cryptsetup now supports truecrypt volumes.
> 
> Two differences i can think of are:
> 1. truecrypt volume header is hidden while luks volume header is open.

Not really. The TrueCrypt headers per default are open.
Only if you use the "hidden Volume" option are they hidden
and they are not hidden very well, as _that_ seems to be 
infeasible. 

> 2. luks can use upto 8 keys while truecrypt only uses one.

No multiple keys in TrueCrupt? That is a serious limitation.

> 3. luks doesnt support hidden volumes.

Wel, yes. Not that they are helping. I know that forensics
people now routinely do entropy analysis of unused and
used disk space, so these volumes are not very hidden 
anymore. Not that they were before. Encryption is for
access control, not for hiding data. For that use
steganography.  

> Is there any other? cryptographically,plain volumes seem to be weaker
> compared to luks volumes.what about luks compared to truecrypt?

Plain is at the same strenght, but you need a good passphrase.
 
> since truecrypt also uses a header,assuming the same use cases and with the
> same number of users,will truecrypt volume's header be corrupted at the
> same rate luks headers will?

Well, plain TrueCrypt volumes seem to include header backups (whith
all the security problems that brings), but not for system encryption.

It should also be noted that so far all reported LUKS header and
keyslot corruptions were due to user error or in one case
distro-installer error (Ubuntu). As Linux treats you like a
responsible adult, the option to corrupt your headers is always
there. And with TrueCrypt system encryption, it seems about
as likely to happen ad with LUKS when using Linux. Windows makes
everything much harder, including damaging your encrypted volume.

> Also,cryptsetup 1.6.0 added supported for opening of truecrypt volumes but
> nothing is currently mentioned on adding support for creating of truecrypt
> volumes.Is the support planned at some point in the future?

I don't think so. See above. Seriously, if you want to create
a TrueCrypt volume under Linux, use the TrueCrypt tools, not
cryptsetup.

Now, if there is interest, I can add a "TrueCrypt" section to 
FAQ section 7, naybe even giving a brief discussion of the
differences to LUKS. 


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

Re: [dm-crypt] few questions on truecrypt and luks

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

> In any case - if anyone using cryptsetup tcrypt commands - please
> report problems and bugs found.
> Also successful stories welcomed - actually I have no idea if anyone
> using it already and feedback (even completely anonymous and possibly
> negative) is very important. Thanks.
>
>
>

>
> - I want to see real users (of already formatted device) before investing
> time to any foreign format or key change operation
>
>
Real users are out there and i am hearing from them and i am playing my
part in advertising truecrypt support in cryptsetup,it helps my project's
adoption :-)

There is,for example,this link
https://tails.boum.org/todo/replace_truecrypt_with_tc-play/

There is this link:
https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#TrueCrypt

cryptsetup can be added to the list. I tried to write an email to  fedora
mailing list asking cryptsetup to be added to the list but my email was
bounced back to me i think its because i was not a member of the list.

I dont think truecrypt support with cannibalize LUKS adoption.From what i
know and what i am hearing,most users of truecrypt in linux use it because
it had a GUI but they would use something else if offered.Case in point
me.I started zuluCrypt specifically because i did not want to use truecrypt
and cryptsetup was the next best thing since i am linux only user.I could
have used truecrypt but i chose not to and using cryptsetup from the
terminal to manage my encrypted volumes in files was annoying enough for me
to do something about it.

I know of users who have switched from truecrypt to cryptsetup because
zuluCrypt now gives them an easy way to manage their encrypted volumes in
files.I think lack of GUI support for LUKS encrypted container  files was
the biggest selling point for truecrypt among linux only users.

I know of atleast one archlinux user who use LUKS and truecrypt volumes in
his system and he was using truecrypt binary for his truecrypt volume and
nautilus for his LUKS volumes.Now he only use zuluCrypt to manage both
volumes.

I do not think linux users will choose truecrypt over luks if comparable
CLI and GUI tools exist for both.

[-- Attachment #2: Type: text/html, Size: 2785 bytes --]

Re: [dm-crypt] few questions on truecrypt and luks

[Milan Broz]

On 14.4.2013 18:56, .. ink .. wrote:
> - I want to see real users (of already formatted device) before
> investing time to any foreign format or key change operation
> 
> 
> Real users are out there and i am hearing from them and i am playing
> my part in advertising truecrypt support in cryptsetup,it helps my
> project's adoption :-)

good :)

> 
> There is this link:
> https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#TrueCrypt
>
>  cryptsetup can be added to the list. I tried to write an email to
> fedora mailing list asking cryptsetup to be added to the list but my
> email was bounced back to me i think its because i was not a member
> of the list.

You need FAS account for wiki edit, fedora-devel should be free...
Whatever... I added cryptsetup link to wiki myself.

> I do not think linux users will choose truecrypt over luks if
> comparable CLI and GUI tools exist for both.

I think the major problem is compatibility with Windows. Nobody
primarily use LUKS there but there are many people formatting disk
with Truecrypt and want to access it under Linux (including myself :)

Thanks,
Milan

Re: [dm-crypt] few questions on truecrypt and luks

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

> >
> > There is this link:
> >
> https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#TrueCrypt
> >
> >  cryptsetup can be added to the list. I tried to write an email to
> > fedora mailing list asking cryptsetup to be added to the list but my
> > email was bounced back to me i think its because i was not a member
> > of the list.
>
> You need FAS account for wiki edit, fedora-devel should be free...
> Whatever... I added cryptsetup link to wiki myself.
>
>
There is this other link :-) :
http://fedoraproject.org/wiki/Talk:Forbidden_items

zuluCrypt should give a comparable and easy to use CLI and GUI replacement.

here is another use who switched from truecrypt to cryptsetup/LUKS because
of an easy to use GUI alternative to encrypted containers in files:
http://www.pclinuxos.com/forum/index.php/topic,114578.msg976670.html#msg976670

[-- Attachment #2: Type: text/html, Size: 1416 bytes --]

Re: [dm-crypt] few questions on truecrypt and luks

[Milan Broz]

On 14.4.2013 18:50, Arno Wagner wrote:

> It should also be said that TrueCrypt format is an "alien" 
> option, in my view primarily for secure data-sharing with
> Windows. (Milan: If the strategic intention is different,
> please correct me.) As such, a full comparison or representation
> as primary format option is probably not a good idea.

I would just use "external on-disk format" intead of "alien"
but this was the plan - easily share data with Windows.

>> 1. truecrypt volume header is hidden while luks volume header is open.
> 
> Not really. The TrueCrypt headers per default are open.
> Only if you use the "hidden Volume" option are they hidden
> and they are not hidden very well, as _that_ seems to be 
> infeasible. 

Hm, maybe you have two different definition of "open".

Truecrypt header should not be detectable without password
knowledge, it starts with 64 bytes random salt and rest is always
encrypted with key derived from password + optionally keyfiles.

All headers are in this format, primary, hidden and even backup header.
They are located just on different positions on disk.

So if "open" means easily detectable, truecrypt header is not
easily detectable. (That's why code need to test all combinations
of ciphers to say that password is wrong...)

>> since truecrypt also uses a header,assuming the same use cases and with the
>> same number of users,will truecrypt volume's header be corrupted at the
>> same rate luks headers will?
> 
> Well, plain TrueCrypt volumes seem to include header backups (whith
> all the security problems that brings), but not for system encryption.

Truecrypt system encryption force you to burn recovery disk
which is able to fix boot loader and header problems.

And it warns you that storing iso image on encrypted disk itself is
not good idea. Twice.
When I tested my code, I reencrypted windows installation and
ignored this advice...
Then I decided to resize encrypted system with some advanced partiton tool...
(If your guess is that tool completely destroyed truecrypt header,
you are right :-)

In fact, this was proof that cryptsetup works here - because I lost
access to recovery disk but I did know passphrase, I was able to open
the device with cryptsetup and backup header located in old position,
read and burn recovery image and fix the whole disk.

Lessons learned :)

Milan

Re: [dm-crypt] few questions on truecrypt and luks

[Milan Broz]

On 14.4.2013 19:48, .. ink .. wrote:
> 
> There is this other link :-) : http://fedoraproject.org/wiki/Talk:Forbidden_items

I would not be surprised that such Fedora pages exist on several locations,
are handled by at least triple committees, sent in, sent back, queried,
lost, found ... I think you know this story :-)

> zuluCrypt should give a comparable and easy to use CLI and GUI
> replacement.

IIRC there were some things in zulucrypt code which do not integrate
well with recent distro desktop envirenments.
But I am not expert on modern desktop concepts (otherwise I had to
ask why e.g. policykit exists and why it uses javascript for policy
definitions...)

Milan

Re: [dm-crypt] few questions on truecrypt and luks

[Arno Wagner]

On Sun, Apr 14, 2013 at 08:48:46PM +0200, Milan Broz wrote:
> On 14.4.2013 18:50, Arno Wagner wrote:
> 
> > It should also be said that TrueCrypt format is an "alien" 
> > option, in my view primarily for secure data-sharing with
> > Windows. (Milan: If the strategic intention is different,
> > please correct me.) As such, a full comparison or representation
> > as primary format option is probably not a good idea.
> 
> I would just use "external on-disk format" intead of "alien"
> but this was the plan - easily share data with Windows.

"alien: in the spirit of the Debian "alien" package. 
But yes.
 
> >> 1. truecrypt volume header is hidden while luks volume header is open.
> > 
> > Not really. The TrueCrypt headers per default are open.
> > Only if you use the "hidden Volume" option are they hidden
> > and they are not hidden very well, as _that_ seems to be 
> > infeasible. 
> 
> Hm, maybe you have two different definition of "open".
> 
> Truecrypt header should not be detectable without password
> knowledge, it starts with 64 bytes random salt and rest is always
> encrypted with key derived from password + optionally keyfiles.
> 
> All headers are in this format, primary, hidden and even backup header.
> They are located just on different positions on disk.
> 
> So if "open" means easily detectable, truecrypt header is not
> easily detectable. (That's why code need to test all combinations
> of ciphers to say that password is wrong...)

Well, not "open plain directly visible" like the LUKS header. 
More like pretty clear that something encrypted is in there
if somebody competent checks. And there will be the TrueCrypt
software on the sytem disk with most users, possibly even with
the partition to mount still remembered. But I agree, calling
this "open" is not fair. But I would not say it really qualifies
as "hidden" either. Maybe "opaque".

> >> since truecrypt also uses a header,assuming the same use cases and with the
> >> same number of users,will truecrypt volume's header be corrupted at the
> >> same rate luks headers will?
> > 
> > Well, plain TrueCrypt volumes seem to include header backups (whith
> > all the security problems that brings), but not for system encryption.
> 
> Truecrypt system encryption force you to burn recovery disk
> which is able to fix boot loader and header problems.

Hmm. I don't remember that, but if so I must have one of
these lying around here somewhere ;-)

> And it warns you that storing iso image on encrypted disk itself is
> not good idea. Twice.
> When I tested my code, I reencrypted windows installation and
> ignored this advice...
> Then I decided to resize encrypted system with some advanced 
> partiton tool...

Where have I heard that story before.... Hmm...

> (If your guess is that tool completely destroyed truecrypt header,
> you are right :-)
> 
> In fact, this was proof that cryptsetup works here - because I lost
> access to recovery disk but I did know passphrase, I was able to open
> the device with cryptsetup and backup header located in old position,
> read and burn recovery image and fix the whole disk.
> 
> Lessons learned :)

:-)

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

Re: [dm-crypt] few questions on truecrypt and luks

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

> > zuluCrypt should give a comparable and easy to use CLI and GUI
> > replacement.
>
> IIRC there were some things in zulucrypt code which do not integrate
> well with recent distro desktop envirenments.
> But I am not expert on modern desktop concepts (otherwise I had to
> ask why e.g. policykit exists and why it uses javascript for policy
> definitions...)
>
> Milan
>

Would like to know what these things are when/if you remember them.
I now test on pclinuxos(kde),fedora( gnome3),ubuntu(unity),opensuse(gnome3)
and i have a user testing it on archlinux(openbox) and i am not aware of
any problem as things work as i intend them to.

[-- Attachment #2: Type: text/html, Size: 930 bytes --]

Re: [dm-crypt] few questions on truecrypt and luks

[octane indice]

Responding to  ".. ink .." <mhogomchungu@gmail.com> :

> Two differences i can think of are:
> 3. luks doesnt support hidden volumes.
>
It does, in a way.

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!)

Then, use loop with a high offset, e.g. more than half of the disk,
create a plain cryptsetup
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.



Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] few questions on truecrypt and luks

[Arno Wagner]

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

Re: [dm-crypt] few questions on truecrypt and luks

[Jonas Meurer]

Hello,

Am 15.04.2013 16:59, schrieb Arno Wagner:
> 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. 

Ocatane, thanks for the example. Arno, thanks for additional
explanations. May I suggest adding this to the FAQ?

Kind regards,
 jonas

>  
>> 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
> 

Re: [dm-crypt] few questions on truecrypt and luks

[octane indice]

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.

>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.

With cryptsetup method, you can have 
unlimited hidden parts, leading to
unlimited suspicions, no matter how many
password you give. 

Don't know which is worse.
-- 
Octane

Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] few questions on truecrypt and luks

[Arno Wagner]

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

Re: [dm-crypt] few questions on truecrypt and luks

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

> 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.
>
>
Reading back through the mailing list and on the discussion on the feature
request on the bug tracker,it seem you just dont like the idea of a hidden
volume or the idea of having a volume inside another volume.

Personally,i prefer PLAIN volumes over LUKS.An example of why is because
when you plug in a LUKS based usb encrypted device to a gnome desktop,the
desktop will give a prompt telling whoever is sitting at the desktop that
the device is encrypted with LUKS and will demand a password to unlock it.I
may not be hiding my stuff from government agencies,but i also do not like
to scream at whoever touches my stuff telling them i have encrypted data.

I dont use truecrypt volumes and i never used the hidden volume feature but
i can see its appeal,it may not be to hide super secret stuff from
governments but simply to have two volumes in one container to
"compartmentalize" sensitive data and not try to hide any of it from
authorities but from say business competitors.

[-- Attachment #2: Type: text/html, Size: 1376 bytes --]

Re: [dm-crypt] few questions on truecrypt and luks

[Arno Wagner]

On Tue, Apr 16, 2013 at 02:27:15PM -0400, .. ink .. wrote:
> > 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.
> >
> >
> Reading back through the mailing list and on the discussion on the feature
> request on the bug tracker,it seem you just dont like the idea of a hidden
> volume or the idea of having a volume inside another volume.

That is a gross simplification. And unfair. Also inaccurate.
While KISS applies, I have no objevtions to increasing complexity
if there are significant security benefits. They are _not_ there
with hidden volumes or embedded volumes, as I have explained.

Crypto is for access control, not for hiding things.
 
> Personally,i prefer PLAIN volumes over LUKS.An example of why is because
> when you plug in a LUKS based usb encrypted device to a gnome desktop,the
> desktop will give a prompt telling whoever is sitting at the desktop that
> the device is encrypted with LUKS and will demand a password to unlock it.I
> may not be hiding my stuff from government agencies,but i also do not like
> to scream at whoever touches my stuff telling them i have encrypted data.

Of cpuse, if you are protecting yourself againt incompetent people...
But this does neither require gidden volumes not embedded volumes.
Plain dm-crypt or plain TrueCrypt is quite enough.
 
> I dont use truecrypt volumes and i never used the hidden volume feature but
> i can see its appeal,

The appeal is there. But the danger is that people vastly over-estimate
the level of security it gives them. 

> it may not be to hide super secret stuff from
> governments but simply to have two volumes in one container to
> "compartmentalize" sensitive data and not try to hide any of it from
> authorities but from say business competitors.

From my observations, "Business competitors" actually are
kept out pretty reliably by open encryption. Just protect
your passphrase adequately. No, the issue at hand is whether
hidden volumes protect you in case somebody can coerce the
passphrase(s) out of you and that somebody does not really
need to prove conclusively that there is a hidden volume.
In those cases, http://xkcd.com/538/ still applies.

Sure, you may go the way of overkill and use hidden
volumes against your kid sister or brother, but that 
does violate KISS and any discussion about encryption here
is worldwide visible and some people may actually have 
to fight off capable attackers. 

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