zuluCrypt vs truecrypt ( shameless plug :-) )

[muungwana]

like to use truecrypt functionality but dont like its none OSI approved OSS license? or its expectancy of a functional sudo setup? or its "sticking out" as a gnome application on a kde environment?

try zuluCrypt. It does what truecrypt does in a sense that it does "on the fly block device encryption" but it uses the linux crypto kernel infrastructure through cryptsetup as a backend, the same backend pclinuxos uses to do disk encryption when a user asks the installation to be done in an encrypted partitions.

It can do what truecrypt does in a sense that it can create encrypt encrypted volumes in both files and partitions and can use both "naked keys" and keyfiles.

In addition, it can now do stand alone file encryption, ala gpg but without the compression and integrity check feature. If all you want is to have a file that need to be opened with a key, zuluCrypt can do that.

Explanation for how it works: http://code.google.com/p/zulucrypt/wiki/FAQ, http://code.google.com/p/zulucrypt/

download page: http://code.google.com/p/zulucrypt/downloads/list

Valuable information should be stored encrypted, why not try zuluCrypt today!!! :-)

disclaimer, this is my project.I started it and i am maintaining it, I started it because i was using cryptsetup to encrypt my valuable information in encrypted files and dolphin/device notifier could not handle them because they work only with volumes in partitions.

[gseaman]

Sounds like a great project but: Page "FAQ," Not Found

The rest of the links work. I've avoided encryption so far, but maybe it's time to start testing.

Galen

[muungwana]

Sounds like a great project but: Page "FAQ," Not Found

The rest of the links work. I've avoided encryption so far, but maybe it's time to start testing.

Galen

A misplaced comma was to blame for the error, fixed now.

[Bald Brick]

I've been playing with zuluCrypt for an hour and a half now, and I really like it. The interface is much simpler and more elegant than TrueCrypt's, and after an initial failed attempt to create an encrypted container in a file it has worked well.

But my first attempt failed. I tried to create a 10GB container and my whole system locked up while zuluCrypt was writing random data to the volume. After that I just created smaller containers with greater success.

At first I didn't manage to copy anything into my containers despite first having cloned the TrueCrypt line in my sudoers file an then starting zuluCrypt as root. I couldn't understand what was wrong until I noticed that "open the volume in read only mode" was ticked in the setup window. This is probably a good safety measure - but only after one has managed to move something into the container.

I loved being able to decide where the volumes should be mounted when opening them. I'll retry creating larger volumes tomorrow, and if I succeed I may well replace TrueCrypt with zuluCrypt.

But I suppose I have to do some googling to find out precisely how secure the encryption is.

 

[muungwana]

But my first attempt failed. I tried to create a 10GB container and my whole system locked up while zuluCrypt was writing random data to the volume. After that I just created smaller containers with greater success.

can you try to create a 10GB file with random data using dd command?
Your system should not have locked up and the problem could be on the file system level
what version of pclinuxos did you try it on?

I tried to create a 10GB volume and i did noe experience any hangs.

Creating a volume over random data is better because it hides how much data is in the volume.
You can create a container file using dd command and then create a cryptsetup volume on it using zuluCrypt-cli. Will post instructions if you want to use this work around.

At first I didn't manage to copy anything into my containers despite first having cloned the TrueCrypt line in my sudoers file an then starting zuluCrypt as root. I couldn't understand what was wrong until I noticed that "open the volume in read only mode" was ticked in the setup window. This is probably a good safety measure - but only after one has managed to move something into the container.

You are not supposed to run it from root's account, or set up sudo for it.
One of its core feature come into play when it is run from a normal user account.

"open the volume in read only mode" option is remembered so you only need to tick it once if you want your volumes to be opened in the same mode.

But I suppose I have to do some googling to find out precisely how secure the encryption is.  

dm-crypt is an infrastructure in the linux kernel that deal with block device encryption,it runs in kernel space.
cryptsetup is a front end to dm-crypt,it runs in user space, demands to be started with root's privileges.
zuluCrypt is a front end to cryptsetup,i am not doing anything clever, all i am doing is take the path to the volume and a passphrase and pass them on to cryptsetup to open the volume.

cryptsetup uses 256 bit aes encryption with cbc mode.
Not having faith in zuluCrypt encryption ultimately means not having faith in the linux crypto functionality.

I can go into the technical s of how these things work if you are curious about them.

[Bald Brick]

But my first attempt failed. I tried to create a 10GB container and my whole system locked up while zuluCrypt was writing random data to the volume. After that I just created smaller containers with greater success.

can you try to create a 10GB file with random data using dd command?

I don't think it will be necessary. I just tried again and created a 10GB volume without any lockups.

Your system should not have locked up and the problem could be on the file system level
what version of pclinuxos did you try it on?

64 bit Test5. (But this time I created the volume on an internal drive; last time I tried to use a removable one. I'll retry with the removable drive tomorrow.)

I tried to create a 10GB volume and i did noe experience any hangs.

Creating a volume over random data is better because it hides how much data is in the volume.
You can create a container file using dd command and then create a cryptsetup volume on it using zuluCrypt-cli. Will post instructions if you want to use this work around.

At first I didn't manage to copy anything into my containers despite first having cloned the TrueCrypt line in my sudoers file an then starting zuluCrypt as root. I couldn't understand what was wrong until I noticed that "open the volume in read only mode" was ticked in the setup window. This is probably a good safety measure - but only after one has managed to move something into the container.

You are not supposed to run it from root's account, or set up sudo for it.
One of its core feature come into play when it is run from a normal user account.

Oh, those were desperate temporary measures when I couldn't write to the volume. Once I noticed and unticked "open the volume in read only mode" I reverted to running the program as a normal user, and it worked well without su or sudo. An elegant program. Thanks, muungwana.

"open the volume in read only mode" option is remembered so you only need to tick it once if you want your volumes to be opened in the same mode.

But I suppose I have to do some googling to find out precisely how secure the encryption is.  

dm-crypt is an infrastructure in the linux kernel that deal with block device encryption,it runs in kernel space.
cryptsetup is a front end to dm-crypt,it runs in user space, demands to be started with root's privileges.
zuluCrypt is a front end to cryptsetup,i am not doing anything clever, all i am doing is take the path to the volume and a passphrase and pass them on to cryptsetup to open the volume.

cryptsetup uses 256 bit aes encryption with cbc mode.
Not having faith in zuluCrypt encryption ultimately means not having faith in the linux crypto functionality.

I can go into the technical s of how these things work if you are curious about them.

Of course I'm curious.

[muungwana]

ok, let me start from the beginning seem a nice place to start

i hope you noticed you could create two type of volumes, "plain" or "luks".

"luks" stands for "linux unified key setup".

pros of luks volume:
1. Upto 8 different keys can open the volume.
2. encryption options are stored in the volume itself( in a luks header) making them more friendly to different tools.
cons:
1. It does not hide the fact that the device or file has encrypted content. You plug a usb drive with a luks based volume and both kde and gnome will say its a luks volume and prompt you for a password.
2. A corrupt luks header will make the volume unopenable and encrypted data lost for ever. If you create a luks volume, take a back up of its header.

pros of plain volume:
1. Not possible to tell if the device or file has plain type encrypted data.
2. Does not use a header and hence not affected by header corruption problem above

cons.
Not having a header means encryption options have to be presented everytime a volume is to be opened and this does not work across different tools since different tools may use different options.

[muungwana]

open a volume and then open a terminal and type the following command:

ls /dev/mapper

You will see a zuluCrypt entry with a part of your device/file.

cryptsetup,like truecrypt use what is called "on the fly encryption". Opening a volume means creating a mapper against the device.

All writes to the mapper get encrypted with the key you provide and then are sent to the drive encrypted.
Reading from the mapper causes encrypted data on disk to be read and then decrypted before being sent to whoever did the read.

All reads outside the mapper will see nothing but garbage.

[muungwana]

This post will make sense if you have atleast a bare minimum of C programming.
zuluCrypt is a front end to cryptseup.

Below source file is what "closes" the volume, ie, remove the mapper against the device/file
http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/close_mapper.c

Below source files are the ones responsible for opening of volumes,ie opening an encryption mapper.

All commands that start with "crypt_" are cryptsetup commands i use to get its services.

http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/open_luks.c
http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/open_plain.c

As you can see, from the above source files, i use cryptsetup to open the mapper and its then upto linux crypto magic to do the encryption.

http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/mount_volume.c

The above source file is the one responsible for mounting the file system on the volume. The mounting is done on the mapper, not the device itself. This way, when you copy a file to the volume though the mount point,the writins is done to the mapper where it gets encrypted by the mapper before it is sent to disk.

make sense? :-)

[Bald Brick]

This post will make sense if you have atleast a bare minimum of C programming.
zuluCrypt is a front end to cryptseup.

Below source file is what "closes" the volume, ie, remove the mapper against the device/file
http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/close_mapper.c

Below source files are the ones responsible for opening of volumes,ie opening an encryption mapper.

All commands that start with "crypt_" are cryptsetup commands i use to get its services.

http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/open_luks.c
http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/open_plain.c

As you can see, from the above source files, i use cryptsetup to open the mapper and its then upto linux crypto magic to do the encryption.

http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/mount_volume.c

The above source file is the one responsible for mounting the file system on the volume. The mounting is done on the mapper, not the device itself. This way, when you copy a file to the volume though the mount point,the writins is done to the mapper where it gets encrypted by the mapper before it is sent to disk.

make sense? :-)

Yes, it does. Running df I had already noticed that whatever was actually mounted had names like /dev/mapper/zuluCrypt-500-NAAN-erikstest-2112, but naturally I had no idea why.

Thank you for your very clear explanations.

By the way, is the installation supposed to create a menu entry for zuluCrypt? I couldn't find one, so I created one myself under "File Tools".

[muungwana]

Yes, it does. Running df I had already noticed that whatever was actually mounted had names like /dev/mapper/zuluCrypt-500-NAAN-erikstest-2112, but naturally I had no idea why.

In that path you provided,500 is the UID( user ID ) of the person who opened the volume.The number is added there to prevent one user from managing another user's opened mapper. The existence of that number will make that mapper you opened completely invisible from within zuluCrypt to any other account other that yours.

Other users can see the path when they browse to "/dev/mapper" folder or from running "df" or "mount" command but they wont be able to do anything with it.The mapper has a permission of 700 and owned by root.

"NAAN" means you open the volume not using the device UUID(used only for hard drives on luks volumes). UUID is used primarily if you create an encrypted volume in a removable media and you want to have a favorite entry in the UI to the drive.

Use of UUID is better because you may plug a usb drive and it may get a device address of "dev/sdc1" now and "/dev/sdd1" later on or "/dev/sde1" at some other time.

The "NAAN" is there to give a consistent length of "/dev/mapper/zuluCrypt-500-XXXX-" regardless of path used,its makes searching of mount points easier.

"erikstest" is the last part of the path to the volume if UUID is not used.

"/home/<user>/erikstest" and "/home/<user>/secretStuff/erikstest" would produce the same "/dev/mapper/zuluCrypt-500-NAAN-erikstest" and you would get a name collision.

The numbers at the end are supposed to be different when different paths are used even when the volume has the same name.
[/quote]

By the way, is the installation supposed to create a menu entry for zuluCrypt? I couldn't find one, so I created one myself under "File Tools".

Completely forgot about this one.
The .desktop file has this line: "Categories=Security;Utility;Qt;" and pclinuxos does not display an icon with that list of categories and hence the .desktop file will have to be changed for pclinuxos.

I found out about this in this post: http://www.pclinuxos.com/forum/index.php/topic,98789.msg838838.html#msg838838

Substituting "Categories=Security;Utility;Qt;" with "Categories=GTK;Settings;X-MandrivaLinux-System-Configuration-Other;" in zulucrypt-v4.5.0/zuluCrypt-gui/CMakeLists.txt" would solve the problem.

From your initial expectation of the tool, i think its best if the default behavior after installation is to have volumes open in read/write mode and let a user change it to read only mode later on.Will change it in the next release. Thanks for the input.

[Just17]

Thank you both for this discussion .....  it has been interesting and enlightening, as I have never used encryption on any of my HDDs.

[muungwana]

But my first attempt failed. I tried to create a 10GB container and my whole system locked up while zuluCrypt was writing random data to the volume. After that I just created smaller containers with greater success.

can you try to create a 10GB file with random data using dd command?

I don't think it will be necessary. I just tried again and created a 10GB volume without any lockups.

Your system should not have locked up and the problem could be on the file system level
what version of pclinuxos did you try it on?

64 bit Test5. (But this time I created the volume on an internal drive; last time I tried to use a removable one. I'll retry with the removable drive tomorrow.)

what kernel are you using in your test5 install?

somebody else in the link below is experiencing more or less the problem you had when copying large file to an external disk As i suspect, the problem could be mostly related to system handling of large file copying under moderate system load. The random data writing process involves writing zeros to the volume through the mapper created with a random key.The encryption of data( zeros in this case ) adds cpu load writing them to disk adds disk I/O load.

http://www.pclinuxos.com/forum/index.php/topic,106565.new.html#new

This could be a wider problem involving copying large files to external media.

[muungwana]

Thank you both for this discussion .....  it has been interesting and enlightening, as I have never used encryption on any of my HDDs.

you can create encryption containers in partitions as well as in files.
The primary reason why i started the project was because kde as well as gnome did not support management of encrypted volumes that reside in files.

[Bald Brick]

But my first attempt failed. I tried to create a 10GB container and my whole system locked up while zuluCrypt was writing random data to the volume. After that I just created smaller containers with greater success.

can you try to create a 10GB file with random data using dd command?

I don't think it will be necessary. I just tried again and created a 10GB volume without any lockups.

Your system should not have locked up and the problem could be on the file system level
what version of pclinuxos did you try it on?

64 bit Test5. (But this time I created the volume on an internal drive; last time I tried to use a removable one. I'll retry with the removable drive tomorrow.)

what kernel are you using in your test5 install?

3.2.18-pclos2.bfs.

somebody else in the link below is experiencing more or less the problem you had when copying large file to an external disk As i suspect, the problem could be mostly related to system handling of large file copying under moderate system load. The random data writing process involves writing zeros to the volume through the mapper created with a random key.The encryption of data( zeros in this case ) adds cpu load writing them to disk adds disk I/O load.

On the other hand, today I managed to create a 30GB volume without any problems on the same removable drive that I failed with yesterday. (A USB2 drive.) I also transferred 22GB of data onto the volume just to test it (more than I'll ever need to encrypt in real life). I think the largest file was about 3.5GB. (If you want me to continue testing with larger files I don't have any above 5GB....)

http://www.pclinuxos.com/forum/index.php/topic,106565.new.html#new

This could be a wider problem involving copying large files to external media.