[dm-crypt] Required kernel crypto interface not available

Franz 169101 at gmail.com
Fri May 16 15:31:49 CEST 2014


On Fri, May 16, 2014 at 4:52 AM, Thomas Bastiani <thom at codehawks.eu> wrote:

> 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
> >>> 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 at 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.
>
>
Very interesting Thomas


> 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
>
>
>
Many thanks Thomas, it seems very similar to what INK wrote. Certainly it
solves my problem
Best
Franz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20140516/38bafb59/attachment.html>


More information about the dm-crypt mailing list