[dm-crypt] few questions on truecrypt and luks

Milan Broz gmazyland at gmail.com
Sun Apr 14 10:40:49 CEST 2013

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.


More information about the dm-crypt mailing list