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