[dm-crypt] Required kernel crypto interface not available
thom at codehawks.eu
Fri May 16 09:52:24 CEST 2014
On 16/05/14 00:04, Franz wrote:
> On Thu, May 15, 2014 at 6:46 PM, .. ink .. <mhogomchungu at gmail.com> wrote:
>> On Thu, May 15, 2014 at 5:26 PM, Franz <169101 at gmail.com> wrote:
>>> Yes I had already seen this zulucrypt and also tomb
>>> http://www.dyne.org/software/tomb/ that seems even more developed that
>>> zulucrypt. But for such a critical task I am willing to trust packages like
>>> cryptsetup and dm-crypt that are signed, incorporated into main
>>> distributions, and certainly checked by many people. But I am unwilling to
>>> trust something posted somewhere in internet, unsigned and unchecked.
>>> Otherwise better to stay with Truecrypt a little more waiting for things
>>> to change.
>>> In any case many thanks to all for the kind help
>> Your statement carries with it a logical inconsistece since you use
>> TrueCrypt, a product that is developed in secrecy,
>> by unknown developers who seem to take extra effort to hide themselves for
>> no obvious reasons who
>> also seem to just put link to a source code dump online once in a
>> while,unchecked and unverified.
>> Why not switching to LUKS since you already seen to trust cryptsetup?
>> what advantages does TrueCrypt volumes have in your use case that makes
>> you want to stick with its encrypted format?
> well you are certainly totally right unfortunately. But truecrypt is at
> least still open source and the installation file is signed. Also, it is a
> very well known product so I suppose that many people audited the source
> code and no big problem ever surfaced. Less important, but still... it is
> already installed and working fine in a VM of my computer.
> Switching to LUCKS would be very interesting. Qubes already uses LUCKS to
> encrypt my disk so every time I start my computer need to put a password
> just to uncrypt it. But can LUCKS work on a file container that I can copy
> and move? I investigated it time ago and found no way to do it. Is there a
> way to do that? Really that would be the solution.
> dm-crypt mailing list
> dm-crypt at saout.de
Regarding the fact that TrueCrypt is safe because it should *obviously*
have been audited, it's not quite as simple. For one thing, proper
audits cost money. Recently Matthew Green and Kenn White setup
http://istruecryptauditedyet.com with the intent of raising enough money
to fund a TrueCrypt audit. You can find the original post here:
As you can see, as of today, TrueCrypt has been partially audited. I say
partially because they did a "security assessment" that does not include
a "cryptographic assessment". They have found a number of potential
issues, although none of them are qualified as "critical". I'll let you
read the initial report for yourself if you like:
My point is generally, TrueCrypt is not as audited as you might think
and the "many eyes" argument is mostly invalid.
As for encrypting a file that you can simply move around, it looks like
it works out of the box. You just need to create a file large enough for
your purposes and then encrypt it and create a file-system as you would
usually do with a block device. Say you want to create a file that's 1GB
# dd if=/dev/zero of=block.luks bs=1G count=1
# cryptsetup luksFormat block.luks
# cryptsetup luksOpen block.luks crypt
# mkfs.ext4 /dev/mapper/crypt
# mkdir /mnt/container
# mount /dev/mapper/crypt /mnt/container
Obviously you could write random data to your container instead of 0's,
You could also use another file system or even a key-file. But you get
More information about the dm-crypt