Re: [dm-crypt] Required kernel crypto interface not available

[Thomas Bastiani <thom@codehawks.eu>]

On 16/05/14 00:04, Franz wrote:
> On Thu, May 15, 2014 at 6:46 PM, .. ink .. <mhogomchungu@gmail.com> wrote:
> 
>>
>>
>> On Thu, May 15, 2014 at 5:26 PM, Franz <169101@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
>>> Best
>>> Franz
>>>
>>
>> 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.
> 
> Best
> Franz
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Hello Franz,

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:

http://blog.cryptographyengineering.com/2013/10/lets-audit-truecrypt.html

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:

https://opencryptoaudit.org/reports/

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
is size:

# 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
the gist.

HTH,
--
Thomas