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

On 1= 6/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 th= at
>>> zulucrypt. But for such a critical task I am willing to trust = packages like
>>> cryptsetup and dm-crypt that are signed, incorporated into mai= n
>>> distributions, and certainly checked by many people. But I am = unwilling to
>>> trust something posted somewhere in internet, unsigned and unc= hecked.
>>>
>>> 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 us= e
>> TrueCrypt, a product that is developed in secrecy,
>> by unknown developers who seem to take extra effort to hide themse= lves for
>> no obvious reasons who
>> also seem to just put link to a source code dump online once in a<= br> >> while,unchecked and unverified.
>>
>> Why not switching to LUKS since you already seen to trust cryptset= up?
>>
>> 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 a= t
> 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 sour= ce
> 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 passwo= rd
> 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 the= re 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://istru= ecryptauditedyet.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/1= 0/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 potenti= al
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
=C2=A0
<= /div>

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 1G= B
is size:

# dd if=3D/dev/zero of=3Dblock.luks bs=3D1G count=3D1
# 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 simi= lar to what INK wrote. Certainly it solves my problem

Best

Franz

--f46d0442685a8ceeec04f9846fb5-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <169101@gmail.com> Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 16 May 2014 15:36:03 +0200 (CEST) Received: by mail-wi0-f174.google.com with SMTP id r20so961501wiv.13 for ; Fri, 16 May 2014 06:36:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <5374FAD5.1000605@gmail.com>

Date: Fri, 16 May 2014 10:13:23 -0300 Message-ID: From: Franz <169101@gmail.com> Content-Type: multipart/alternative; boundary=089e01493f58a47acd04f9842d4f Subject: Re: [dm-crypt] Required kernel crypto interface not available List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ".. ink .." Cc: "dm-crypt@saout.de" --089e01493f58a47acd04f9842d4f Content-Type: text/plain; charset=UTF-8 On Fri, May 16, 2014 at 12:00 AM, .. 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 > > 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 --089e01493f58a47acd04f9842d4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, May 16, 2014 at 12:00 AM, .. ink .. <<= a href=3D"mailto:mhogomchungu@gmail.com" target=3D"_blank">mhogomchungu@gma= il.com> wrote:

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

=C2=A0
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 fil= e among other files. Many thanks INK you are great!

=C2=A0
You should kno= w that LUKS header volume is partially open and hence its readily obvious t= he volume is a LUKS volume
and hence you arent hiding that mu= ch 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: http= s://code.google.com/p/cryptsetup/wiki/Cryptsetup140

I do not get clearly the advan= tage of having the header separated from the container. If I have header an= d 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?
=C2=A0

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

<= /div>

=C2=A0

And to make a 200 MB container?

=C2=A0
That will be
dd if=3D/dev/urandom of=3Dvolume bs=3D1024 count=3D200000

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

=
Just start with bs =3D1024 and read for yourself "one kilo byte&q= uot;.

Then have "count=3D2" and then read for yourself "= ;two kilo bytes" because now you will have bs=3D1024 count=3D2
and both amounts to 2048(two kilobytes)

From the a= bove 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.
=C2=A0

Well many thanks indeed INK good night

You are welco= me. If i can introduce myself to you, i am the developer of zuluCrypt. I st= arted 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 t= erminal got really annoying really fast.I should also say i am not a crypts= etup developer, i just hang out here to keep track of a project i depend on= .

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

Very interesting IN= K, and clear. Now I am sorry wrote did not trust zuluCrypt. These mail list= s 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 m= y trust was misplaced with bad consequences, but at the same time all the b= est things I accomplished in life=C2=A0 were based on trust. So...

Best

Franz

--089e01493f58a47acd04f9842d4f-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 16 May 2014 23:50:50 +0200 (CEST) Received: by mail-ig0-f175.google.com with SMTP id uq10so1349164igb.14 for ; Fri, 16 May 2014 14:50:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <5374FAD5.1000605@gmail.com>

From: ".. ink .." Date: Fri, 16 May 2014 17:23:02 -0400 Message-ID: Content-Type: multipart/alternative; boundary=90e6ba1efcaef18daf04f98b057e Subject: Re: [dm-crypt] Required kernel crypto interface not available List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Franz <169101@gmail.com>, "dm-crypt@saout.de" --90e6ba1efcaef18daf04f98b057e Content-Type: text/plain; charset=UTF-8 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 --90e6ba1efcaef18daf04f98b057e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

=C2=A0

I do not get clearly the advantage of having the header separated from th= e 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 kno= w there is something hidden.

yes

But isn't the same happening if container and header ar= e 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 i= s this if in any case they cannot open it?
=C2=A0

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 encryp= ted volume but at least you will get the opportunity to try.A LUKS volume w= ith attached header will not give you this opportunity and a detached heade= r 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