[dm-crypt] Required kernel crypto interface not available

[dm-crypt] Required kernel crypto interface not available

[Franz]

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

Hello,

I am trying to follow this tutorial to mount truecrypt volumes with
cryptsetup:
http://forums.fedoraforum.org/showthread.php?p=1698596#post1698596
But I'm getting this error:

"Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded."

So tried to load the kernel module, but got other error:

"[user@cryptsetup ~]$ sudo modprobe algif_skcipher
modprobe: FATAL: Module algif_skcipher not found."

Is there a solution?

Best

Franz

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

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

[Arno Wagner]

Hi Franz,

this is not a cryptsetup problem. You need to get a kernel
that has that module or compile one yourself. There really is 
nothing else to do.

Arno

On Thu, May 15, 2014 at 04:58:29 CEST, Franz wrote:
> Hello,
> 
> I am trying to follow this tutorial to mount truecrypt volumes with
> cryptsetup:
> http://forums.fedoraforum.org/showthread.php?p=1698596#post1698596
> But I'm getting this error:
> 
> "Required kernel crypto interface not available.
> Ensure you have algif_skcipher kernel module loaded."
> 
> So tried to load the kernel module, but got other error:
> 
> "[user@cryptsetup ~]$ sudo modprobe algif_skcipher
> modprobe: FATAL: Module algif_skcipher not found."
> 
> Is there a solution?
> 
> Best
> 
> Franz

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
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
----
A good decision is based on knowledge and not on numbers. -  Plato

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

[Milan Broz]

See cryptsetup man page

 TCRYPT  extension requires kernel userspace crypto API to be available (introduced in Linux kernel 2.6.38).  If you are configur‐
 ing kernel yourself,  enable  "User-space  interface  for  symmetric  key  cipher  algorithms"  in  "Cryptographic  API"  section
 (CRYPTO_USER_API_SKCIPHER .config option).

Milan

On 05/15/2014 04:58 AM, Franz wrote:
> Hello,
> 
> I am trying to follow this tutorial to mount truecrypt volumes with cryptsetup:
> http://forums.fedoraforum.org/showthread.php?p=1698596#post1698596
> But I'm getting this error:
> 
> "Required kernel crypto interface not available.
> Ensure you have algif_skcipher kernel module loaded."
> 
> So tried to load the kernel module, but got other error:
> 
> "[user@cryptsetup ~]$ sudo modprobe algif_skcipher
> modprobe: FATAL: Module algif_skcipher not found."
> 
> Is there a solution?
> 
> Best
> 
> Franz
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

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

[Franz]

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

Thanks for the kind and informed reply.

My kernel is 3.12.14-4. I am no developer nor kernel configurator. Just a
user. It seems this means I cannot use this for the foreseeable future.

Do you know any other script to mount a crypted container (contained in a
file) that may work for a simple user like me.

Well if it does not exist I'll go on using trucrypt.

Best and thanks

Fran


On Thu, May 15, 2014 at 2:35 PM, Milan Broz <gmazyland@gmail.com> wrote:

> See cryptsetup man page
>
>  TCRYPT  extension requires kernel userspace crypto API to be available
> (introduced in Linux kernel 2.6.38).  If you are configur‐
>  ing kernel yourself,  enable  "User-space  interface  for  symmetric  key
>  cipher  algorithms"  in  "Cryptographic  API"  section
>  (CRYPTO_USER_API_SKCIPHER .config option).
>
> Milan
>
> On 05/15/2014 04:58 AM, Franz wrote:
> > Hello,
> >
> > I am trying to follow this tutorial to mount truecrypt volumes with
> cryptsetup:
> > http://forums.fedoraforum.org/showthread.php?p=1698596#post1698596
> > But I'm getting this error:
> >
> > "Required kernel crypto interface not available.
> > Ensure you have algif_skcipher kernel module loaded."
> >
> > So tried to load the kernel module, but got other error:
> >
> > "[user@cryptsetup ~]$ sudo modprobe algif_skcipher
> > modprobe: FATAL: Module algif_skcipher not found."
> >
> > Is there a solution?
> >
> > Best
> >
> > Franz
> >
> >
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
>

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

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

[Milan Broz]

On 05/15/2014 08:55 PM, Franz wrote:
> Thanks for the kind and informed reply.
> 
> My kernel is 3.12.14-4. I am no developer nor kernel configurator. Just a user. It seems this means I cannot use this for the foreseeable future.

Report bug to your distro then.

> 
> Do you know any other script to mount a crypted container (contained in a file) that may work for a simple user like me.

For new TrueCrypt containers (XTS mode) you can also use tcplay (if it is in your distro).

Milan

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

[.. ink ..]

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

On Thu, May 15, 2014 at 2:55 PM, Franz <169101@gmail.com> wrote:

> Thanks for the kind and informed reply.
>
> My kernel is 3.12.14-4. I am no developer nor kernel configurator. Just a
> user. It seems this means I cannot use this for the foreseeable future.
>
> What distribution are you using?
Your kernel is modern enough and should have the required functionality
build in by default,if not,you should file a bug with the distribution.The
reason why things do not work probably is because you are making a mistake
somewhere.


> Do you know any other script to mount a crypted container (contained in a
> file) that may work for a simple user like me.
>
> Well if it does not exist I'll go on using trucrypt.
>
>
Any reason why you want to do this from a script? If you want the volume at
be unlocked at boot time,i believe systemd has provisions to make it
possible if you are running a systemd managed system.

There is a GUI tool called zuluCrypt[1] that will allow you to mount your
truecrypt volume. Info on how to install binaries in fedora is here[2]

[1] https://code.google.com/p/zulucrypt/

[2] http://forums.fedoraforum.org/showthread.php?t=292320

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

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

[.. ink ..]

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

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?

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

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

[Franz]

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

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

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

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

[.. ink ..]

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

On Thu, May 15, 2014 at 7:04 PM, Franz <169101@gmail.com> wrote:



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

Yes it can. Below is an example of how to create a 10MB LUKS volume in an
image file that can be moved around
the same way you would move around truecrypt volume image file

Summary of below steps:
1. create a 10MB image file
2. create a LUKS volume on the image file
3. open the LUKS volume.
4. put a file system on the volume.
5. close the the volume.
6. ?????
7. profit!!!!! :-)

dd if=/dev/urandom of=luks.img bs=1024 count=10000
cryptsetup luksFormat luks.img
cryptsetup luksOpen luks.img luks
mkfs.ext4 /dev/mapper/luks
cryptsetup luksClose luks

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

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

[Franz]

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

On Thu, May 15, 2014 at 8:43 PM, .. ink .. <mhogomchungu@gmail.com> wrote:

>
> On Thu, May 15, 2014 at 7:04 PM, Franz <169101@gmail.com> wrote:
>
>
>
>> 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
>>
>
> Yes it can. Below is an example of how to create a 10MB LUKS volume in an
> image file that can be moved around
> the same way you would move around truecrypt volume image file
>
> Summary of below steps:
> 1. create a 10MB image file
> 2. create a LUKS volume on the image file
> 3. open the LUKS volume.
> 4. put a file system on the volume.
> 5. close the the volume.
> 6. ?????
> 7. profit!!!!! :-)
>
> dd if=/dev/urandom of=luks.img bs=1024 count=10000
> cryptsetup luksFormat luks.img
> cryptsetup luksOpen luks.img luks
> mkfs.ext4 /dev/mapper/luks
> cryptsetup luksClose luks
>
>
>
Wow it works!! I cannot believe it was that easy. Also I was able to create
a container called only test, without the .img extension to hidden the file
among other files. Many thanks INK you are great!

I was breaking my head for nothing. Well it is easy when you know how to do
it. Otherwise...  Goodby to Truecrypt now.

And to make a 200 MB container?

Well many thanks indeed INK good night

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

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

[.. ink ..]

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

On Thu, May 15, 2014 at 9:58 PM, Franz <169101@gmail.com> wrote:



> Wow it works!! I cannot believe it was that easy. Also I was able to
> create a container called only test, without the .img extension to hidden
> the file among other files. Many thanks INK you are great!
>
>
You should know that LUKS header volume is partially open and hence its
readily obvious the volume is a LUKS volume
and hence you arent hiding that much if anything. If you want to use LUKS
while hiding the header, create the
volume with a detached header,info on how to do so is here:
https://code.google.com/p/cryptsetup/wiki/Cryptsetup140

Alternative to have a completely hidden volume while not using a detached
header is to create a plain dm-crypt volume using cryptsetup.

>

And to make a 200 MB container?
>
>
That will be
dd if=/dev/urandom of=volume bs=1024 count=200000

The formula is simple,volume size = block size(bs) * count

Just start with bs =1024 and read for yourself "one kilo byte".
Then have "count=2" and then read for yourself "two kilo bytes" because now
you will have bs=1024 count=2
and both amounts to 2048(two kilobytes)

From the above just start adding "zeros" to count while saying:

"twenty kilobytes"
"two hunded kilobytes"
"two megabytes"
"twenty megabytes"
"two hundred megabytes"

and stop when you have reached the desired size,get the idea? This is the
thinking i usually use when creating image files using "dd" command.


Well many thanks indeed INK good night
>

You are welcome. If i can introduce myself to you, i am the developer of
zuluCrypt. I started the project because i did not want
to use TrueCrypt simply because it didnt feel like a linux native solution
and using cryptsetup from the terminal got really annoying really fast.I
should also say i am not a cryptsetup developer, i just hang out here to
keep track of a project i depend on.

With crypsetup,you can manage 3 different volumes, TrueCrypt volumes,LUKS
volumes and PLAIN volumes.Each has a pro and associated cons. I wrote a
"simple" comparison btw them in an article about zuluCrypt in the may issue
of pclinuxos magazine,you can read the online version of the article here:
http://pclosmag.com/html/Issues/201405/page10.html

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

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

[Arno Wagner]

On Fri, May 16, 2014 at 05:00:55 CEST, .. ink .. wrote:
> On Thu, May 15, 2014 at 9:58 PM, Franz <169101@gmail.com> wrote:
> 
> 
> 
> > Wow it works!! I cannot believe it was that easy. Also I was able to
> > create a container called only test, without the .img extension to hidden
> > the file among other files. Many thanks INK you are great!
> >
> >
> You should know that LUKS header volume is partially open and hence its
> readily obvious the volume is a LUKS volume
> and hence you arent hiding that much if anything. If you want to use LUKS
> while hiding the header, create the
> volume with a detached header,info on how to do so is here:
> https://code.google.com/p/cryptsetup/wiki/Cryptsetup140
> 
> Alternative to have a completely hidden volume while not using a detached
> header is to create a plain dm-crypt volume using cryptsetup.

And while you consider that, make very sure you have your
attacker model right. Hiding encrypted volumes is a tricky,
uncertain business and, if discoverted or suspected, you
can land in a lot of hot water.

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
----
A good decision is based on knowledge and not on numbers. -  Plato

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

[Franz]

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

On Fri, May 16, 2014 at 12:00 AM, .. ink .. <mhogomchungu@gmail.com> wrote:

>
> On Thu, May 15, 2014 at 9:58 PM, Franz <169101@gmail.com> wrote:
>
>
>
>> Wow it works!! I cannot believe it was that easy. Also I was able to
>> create a container called only test, without the .img extension to hidden
>> the file among other files. Many thanks INK you are great!
>>
>>
> You should know that LUKS header volume is partially open and hence its
> readily obvious the volume is a LUKS volume
> and hence you arent hiding that much if anything. If you want to use LUKS
> while hiding the header, create the
> volume with a detached header,info on how to do so is here:
> https://code.google.com/p/cryptsetup/wiki/Cryptsetup140
>
>
I do not get clearly the advantage of having the header separated from the
container. If I have header and container together, you tell that anybody
can easily find this is a LUKS container. They cannot open it but they know
there is something hidden.

But isn't the same happening if container and header are separated? I
suppose that as well they can easily find the header (OR NOT?). They cannot
open the container, but they know there is something hidden. Yes they do
not know WHERE it is hidden in this case, but how important is this if in
any case they cannot open it?


> Alternative to have a completely hidden volume while not using a detached
> header is to create a plain dm-crypt volume using cryptsetup.
>
>>
>
> And to make a 200 MB container?
>>
>>
> That will be
> dd if=/dev/urandom of=volume bs=1024 count=200000
>
> The formula is simple,volume size = block size(bs) * count
>
> Just start with bs =1024 and read for yourself "one kilo byte".
> Then have "count=2" and then read for yourself "two kilo bytes" because
> now you will have bs=1024 count=2
> and both amounts to 2048(two kilobytes)
>
> From the above just start adding "zeros" to count while saying:
>
> "twenty kilobytes"
> "two hunded kilobytes"
> "two megabytes"
> "twenty megabytes"
> "two hundred megabytes"
>
> and stop when you have reached the desired size,get the idea? This is the
> thinking i usually use when creating image files using "dd" command.
>
>
> Well many thanks indeed INK good night
>>
>
> You are welcome. If i can introduce myself to you, i am the developer of
> zuluCrypt. I started the project because i did not want
> to use TrueCrypt simply because it didnt feel like a linux native solution
> and using cryptsetup from the terminal got really annoying really fast.I
> should also say i am not a cryptsetup developer, i just hang out here to
> keep track of a project i depend on.
>
> With crypsetup,you can manage 3 different volumes, TrueCrypt volumes,LUKS
> volumes and PLAIN volumes.Each has a pro and associated cons. I wrote a
> "simple" comparison btw them in an article about zuluCrypt in the may issue
> of pclinuxos magazine,you can read the online version of the article here:
> http://pclosmag.com/html/Issues/201405/page10.html
>

Very interesting INK, and clear. Now I am sorry wrote did not trust
zuluCrypt. These mail lists are dangerous: you never know who you are
speaking with :-). Trust is the weak and strong point. I am getting older
and cannot tell how many times my trust was misplaced with bad
consequences, but at the same time all the best things I accomplished in
life  were based on trust. So...

Best
Franz

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

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

[.. ink ..]

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

On Fri, May 16, 2014 at 9:13 AM, Franz <169101@gmail.com> wrote:


> I do not get clearly the advantage of having the header separated from the
> container. If I have header and container together, you tell that anybody
> can easily find this is a LUKS container. They cannot open it but they know
> there is something hidden.
>
> yes

> But isn't the same happening if container and header are separated? I
> suppose that as well they can easily find the header (OR NOT?). They cannot
> open the container, but they know there is something hidden. Yes they do
> not know WHERE it is hidden in this case, but how important is this if in
> any case they cannot open it?
>
>
with a detached header,when somebody gets a hold of the header less
volume,they will not know the volume has encrypted data using LUKS,at
best,they may suspect but not know.You will not get many successes when
trying to convince somebody that your 200MB file made up of
cryptographically sound random data is not an encrypted volume but at least
you will get the opportunity to try.A LUKS volume with attached header will
not give you this opportunity and a detached header seeks to give it back.

Which one of the supported cryptsetup volume you should use depends on your
use case but they all largely give marginal benefits when compared to each
other for most use cases

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

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

[Franz]

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

On Fri, May 16, 2014 at 6:23 PM, .. ink .. <mhogomchungu@gmail.com> wrote:

>
> On Fri, May 16, 2014 at 9:13 AM, Franz <169101@gmail.com> wrote:
>
>
>> I do not get clearly the advantage of having the header separated from
>> the container. If I have header and container together, you tell that
>> anybody can easily find this is a LUKS container. They cannot open it but
>> they know there is something hidden.
>>
>> yes
>
>> But isn't the same happening if container and header are separated? I
>> suppose that as well they can easily find the header (OR NOT?). They cannot
>> open the container, but they know there is something hidden. Yes they do
>> not know WHERE it is hidden in this case, but how important is this if in
>> any case they cannot open it?
>>
>>
> with a detached header,when somebody gets a hold of the header less
> volume,they will not know the volume has encrypted data using LUKS,at
> best,they may suspect but not know.You will not get many successes when
> trying to convince somebody that your 200MB file made up of
> cryptographically sound random data is not an encrypted volume but at least
> you will get the opportunity to try.A LUKS volume with attached header will
> not give you this opportunity and a detached header seeks to give it back.
>
> Which one of the supported cryptsetup volume you should use depends on
> your use case but they all largely give marginal benefits when compared to
> each other for most use cases
>
>
Many thanks INK. Finally did not try to separate the header, but got
everything working now and can start using it, with a little  .sh file than
runs the steps you indicated in your second post. For my wife, that
cordially hates computers,  it is easier to use it this way than following
previous truecrypt GUI steps.  Now she only has to open a terminal, write
in an alias and fill in a password, when asked for it  :-). My plan is to
periodically save the file for backup.

Best

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

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

[Arno Wagner]

On Fri, May 16, 2014 at 03:58:31 CEST, Franz wrote:
> On Thu, May 15, 2014 at 8:43 PM, .. ink .. <mhogomchungu@gmail.com> wrote:
> > Summary of below steps:
> > 1. create a 10MB image file
> > 2. create a LUKS volume on the image file
> > 3. open the LUKS volume.
> > 4. put a file system on the volume.
> > 5. close the the volume.
> > 6. ?????
> > 7. profit!!!!! :-)
> >
> > dd if=/dev/urandom of=luks.img bs=1024 count=10000
> > cryptsetup luksFormat luks.img
> > cryptsetup luksOpen luks.img luks
> > mkfs.ext4 /dev/mapper/luks
> > cryptsetup luksClose luks
> >
> >
> >
> Wow it works!! I cannot believe it was that easy. Also I was able to create
> a container called only test, without the .img extension to hidden the file
> among other files. Many thanks INK you are great!
> 
> I was breaking my head for nothing. Well it is easy when you know how to do
> it. Otherwise...  Goodby to Truecrypt now.
> 
> And to make a 200 MB container?
> 

For a less obscure way to create files in any size you
like seel also FAQ item 2.6. Can also be done with /dev/urandom,
but that gets really slow on larger files, see FAQ Item 2.19
for the idea how to wipe faster.

The FAQ ist at 
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

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
----
A good decision is based on knowledge and not on numbers. -  Plato

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

[Thomas Bastiani]

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

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

[Franz]

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

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

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

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