This project has moved and is read-only. For the latest updates, please go here.

Too long for volume formatting

Topics: Feature Requests, Technical Issues
Mar 13, 2016 at 6:23 PM
I'm following the guide as found in: https://veracrypt.codeplex.com/wikipage?title=Beginner%27s%20Tutorial

Unfortunately it's taking an infinite amount of time in step 11 and still does not finish the job. Why? I left it for around 3 hours and the job was still not done. The Hard disk that I'm trying to format is 1 GB. I'm formatting it for linux only.
Mar 21, 2016 at 8:17 PM
I have done 1 gig HD's and yes it takes a long time as the drive is also completely filled with random information as it is formatted. A windows quick format erases nothing on the drive.
Mar 24, 2016 at 5:46 PM
I was very surprised by veracrypt because formatting a large volume kept giving me errors. I couldn't have made any mistake with the password because I use a password manager for strong passwords. I think it's more for windows clients than linux ones. I went for Zulucrypt.
Mar 25, 2016 at 10:10 PM
Edited Mar 25, 2016 at 10:12 PM
1GB or 1TB? 1GB takes less than 20 seconds even on quite old hard drive ;-) 1TB takes several hours, because veracrypt needs to overwrite all the sectors and it needs time. Modern hard drives write 150-200MB/s on the beginning and less than 100MB/s on the end, so you have to count little less than 10 seconds per each GB written. If some other tool works quicker, it does not do its job good and I'd not trust it. I have "formatted" quite a few disks using VC in sizes from 1 to 3TB (MBR and GPT) and never received any error. If you have received some error, you should tell which one it was, you may have faulty hdd or some other hardware.
Mar 26, 2016 at 12:22 AM
Isn't Zulucrypt described correctly as follows?

"Software description: zuluCrypt is a front end to cryptsetup and tcplay and it allows easy management of encrypted block devices "

So, just a front end for other tools?
Mar 26, 2016 at 7:06 AM
zulucrypt can read an encrypted HD done with truecrypt or veracrypt! But vice versa no. When installing Zulucrypt one has to be careful to install all dependencies (one of them being cryptsetup). It is for linux users only.
Mar 26, 2016 at 1:47 PM
Edited Mar 26, 2016 at 1:50 PM
zuluCrypt is a front end to cryptsetup and tcplay.Both of these projects are a front end to dm-crypt,the infrastructure in the linux kernel that deals with block device encryption.

VeraCrypt and TrueCrypt in linux by default,are also just a front end to dm-crypt.

zuluCrypt can create and unlock TrueCrypt volumes as well as VeraCrypt volumes in addition to LUKS volumes and plain dm-crypt volumes. zuluCrypt can unlock VeraCrypt volumes created by VeraCrypt and VeraCrypt can unlock VeraCrypt volumes created by zuluCrypt.

Everybody can unlock volumes created by everybody else :-)

When creating any supported volume in a hard drive,zuluCrypt gives an option to fill the device with random data first or for the step to be bypassed. If a user decides to take the option,they can cancel it at any time they want but they can not resume from where they left off if they want to continue with the random data writing process.

ps:
current maintainer of zuluCrypt.
Mar 26, 2016 at 2:09 PM
Thanks mhogomchungu!

Okay, so if I have an older TC volume created on Winblows.... can I open that with just cryptsetup [dm-crypt (perhaps offset or not for LUKS headers)] directly, and there is or is not LUKS headers? Without needing tcplay on Linux?
Mar 26, 2016 at 2:53 PM
Edited Mar 26, 2016 at 2:55 PM
affinity wrote:
Thanks mhogomchungu!

Okay, so if I have an older TC volume created on Winblows.... can I open that with just cryptsetup [dm-crypt (perhaps offset or not for LUKS headers)] directly, and there is or is not LUKS headers? Without needing tcplay on Linux?
define "older". A few years may have passed since you created your TrueCrypt volume but you maybe using its latest volume format.

yes,cryptsetup will probably be able to open your volume since it supports older TrueCrypt volume formats.
cryptsetup can only unlock TrueCrypt and VeraCrypt volumes,it can not create them.

tcplay( and by implication,zuluCrypt) supports only the most recent TrueCrypt format version and it may not work with your "older" volume.

tcplay can create and unlock TrueCrypt and VeraCrypt volumes and zuluCrypt uses it as a backend instead of cryptsetup because it can both create and unlock.

All TrueCrypt,VeraCrypt,cryptsetup,tcplay,zuluCrypt does is process the volume header to get cryto info necessary to create the encryption mapper.

After you have unlocked your volume with any of these mentioned projects,open the terminal,log in to root account and then run "dmsetup table --showkeys".

The information in the output you see is the only information these tools send to dm-crypt when asking it to create an encryption mapper.

The fourth entry from the right is the volume's master key. With this info,you can skip all these front ends and manually go straight to dm-crypt and create the encryption mapper yourself but you will then have the problem of how to securely keep these informations.

Read up on "dmsetup" to see how you can use it to create and destroy encryption mappers and maybe you can come up with your encrypted volume format :-)
Mar 26, 2016 at 3:28 PM
Sept 2012 might be the oldest TC file.

"only the most recent TrueCrypt format version " -- when did it change? Is there a reference to the /various/ formats?

Lots of interesting stuff once again, thank you.

Don't think I'll create my own encrypted volume format though. Sometimes, certain things, are better left to those that know it well, really well, the old WEP "lack of security" issue being one of those times.

I have used tcplay before, usually that would mean that it was from a Debian package, but it isn't installed on any of my machines right now. I may have used it within Tails once or twice some time ago.
Mar 26, 2016 at 4:37 PM
VeraCrypt and tcplay can work only with TrueCrypt volumes that uses xts mode.

TrueCrypt started creating volumes in this mode in version 5.0[1] and this version was released in 2008!!!!

"older" TrueCrypt volumes are those that were created with versions below 5.0 with 5 being the current format version.

tcplay complains with previous versions as seen here[2] and creates its volumes with version 5 as seen here[3][4]

[1] http://filehippo.com/download_truecrypt/changelog/3769/

[2] https://github.com/mhogomchungu/zuluCrypt/blob/c43a7a93df195624a112867644e2a015751a1bed/external_libraries/tc-play/hdr.c#L112

[3] https://github.com/mhogomchungu/zuluCrypt/blob/c43a7a93df195624a112867644e2a015751a1bed/external_libraries/tc-play/hdr.c#L214

[4] https://github.com/mhogomchungu/zuluCrypt/blob/c43a7a93df195624a112867644e2a015751a1bed/external_libraries/tc-play/hdr.c#L219
Mar 26, 2016 at 4:49 PM
Dear mhogomchungu

I found zulucrypt perfect in many ways. Yet I found one simple thing which is annoying. One can delete the volume created very easily just by pressing delete. Is there a way of protecting an encrypted volume created by Zulucrypt?
Mar 26, 2016 at 5:24 PM
danbarmt wrote:
Dear mhogomchungu

I found zulucrypt perfect in many ways. Yet I found one simple thing which is annoying. One can delete the volume created very easily just by pressing delete. Is there a way of protecting an encrypted volume created by Zulucrypt?
Where do you press this "delete" button you are speaking of?

When creating a new volume in a device,you first get a prompt with a warning that says all data on the device will be erased if you proceeds,then you get a second prompt that asks if the device should be written first with random data. Are you speaking about this point where an accidentally clicking the "yes" button will lead to destruction of whatever data was on the device?

If yes,then i noticed this too and the git version now disables the "yes" button for two seconds and hence it can not accidentally be clicked.
Mar 26, 2016 at 5:33 PM
The delete is the key button found on the keyboard (under insert). I'm using zulucrypt 4.8.

I have created a zulucrypt volume on an external hard disk. I wanted to protect some files so I put them into this volume. After some days (ie after creating the volume), I was playing around and accidentally hit the delete button. Incredibly the volume was gone with all the files contained therein!!!
Mar 26, 2016 at 6:15 PM
If i understood you correctly,you created an encrypted volume in a container file and then you put this container file in an external hard drive and then you accidentally deleted this container file when you accidentally clicked the "delete" button,correct?

If the container file is on a folder you have write access to,then you can easily delete it and i do not think zuluCrypt can prevent this.

If you unlock a volume in read/write mode,then you can easily delete all contents of the container.

Fooling around with permissions on the host folder could prevent accidental deletion of files but i have never tested it.

I am all ears if anybody can prevent the above at an application level.

Linux file systems do not delete files when they are deleted while still in use,they just remove them from a folder list but the files are still there and i think you could have got your container back if you did not turn off the computer and you left the volume open.

zuluCrypt has an option to mount volumes in read only mode and this option is displayed very prominently because i use it all the time and i unlock a volume in read/write mode only if i want change its contents and i remount it read only as soon as i am done changing its contents.

zuluMount can mount unencrypted file systems and it has the option to mount them in read only mode too.
Mar 26, 2016 at 6:35 PM
Edited Mar 26, 2016 at 6:53 PM
thanks for the information. I noted that one could open the volume in read only mode.

I just created a small volume in a container file. I just right clicked in the volume and got a root privilege (ie only in root one can write or delete). I closed the volume. I closed Zulucrypt too. Than I opened computer (under places) and I could still delete the volume at will....no protection whatsoever.

So if somebody gets hold of the external HD, even though I'm sure that nobody will be allowed to read the contents, they could easily delete it!
Mar 26, 2016 at 6:57 PM
So, you want the tool to make any newly created files owned by root and with no rights for groups or world? Thus, protecting the file from deletion by an ordinary user and no hope to stop a root privileged user?
Mar 26, 2016 at 7:03 PM
I want to be the only user to delete that volume. I hope I'm clear enough in my wording.
Mar 26, 2016 at 8:22 PM
danbarmt wrote:
thanks for the information. I noted that one could open the volume in read only mode.

I just created a small volume in a container file. I just right clicked in the volume and got a root privilege (ie only in root one can write or delete). I closed the volume. I closed Zulucrypt too. Than I opened computer (under places) and I could still delete the volume at will....no protection whatsoever.

So if somebody gets hold of the external HD, even though I'm sure that nobody will be allowed to read the contents, they could easily delete it!
A way to prevent the accidental deletion is to use the sticky bit feature on directories[1][2]

[1] http://askubuntu.com/questions/432699/what-is-the-t-letter-in-the-output-of-ls-ld-tmp
[2] http://www.thegeekstuff.com/2013/02/sticky-bit/
Mar 28, 2016 at 8:56 AM
thanks for your informative answer. I tried it (t representing the sticky bit) on normal files and it worked. I tried it on zulucrypt folder (container) and it didn't work.

Now maybe because it's a zulucrypt crea ted file or because it's on an external hard disk. I tried a dot in front (to make it hidden), it works in desktop or home folder but it does not work on an external hard disk!
Mar 28, 2016 at 9:42 AM
Sticky bit is effective only on the folder setting, not a file setting; the external drive would work the same, unless it is obviously not a *nix file system, it which case hiding is done differently.
Mar 28, 2016 at 12:41 PM
thanks for answering affinity.

The external hard disk was formatted as ext4.
Does it mean that there is no way of hiding a file (ie of zulucrypt) ?
Mar 28, 2016 at 12:50 PM
The encrypted container is ext4? So is the drive that the container is stored upon? Are you sure?
Mar 28, 2016 at 3:47 PM
I'm sure because that's my favourite formatting style. I always format in ext 4.
Mar 28, 2016 at 5:26 PM
Okay, can you do an ls -lad for the directory that the container is / was stored in on the external drive?
Mar 28, 2016 at 5:52 PM
Edited Mar 28, 2016 at 5:55 PM
this is the terminal's response:

drwxr-xr-x 56 xxxxxxxxxx 4096 Mar 28 18:43

Do I need to cd to somewhere else?
Mar 28, 2016 at 5:57 PM
Okay, well it is missing the sticky bit setting for the directory, that's what you need to stop anyone deleting the container file without being the owner of the file or having root privileges.

It should look like this:
drwxr-xr-t 56 xxxxxxxxxx 4096 Mar 28 18:43

Notice the "t" in place of the last "x" in the permissions.
Mar 28, 2016 at 6:13 PM
I agree but it won't accept the 't' because one it is an external hard disk (it's not a folder nor a directory) and secondly the zulucrypt container is not a folder.

I did create folders with a 't' in the home and desktop places but was not successful on the external hard disk. Maybe there is a mistake with the path? Well I'm copying the one used by zulucrypt....../media/name/name of external HD/name of folder
Mar 28, 2016 at 6:51 PM

dd if=/dev/zero of=dummyfile bs=4M count=10

10+0 records in
10+0 records out
41943040 bytes (42 MB) copied, 0.198134 s, 212 MB/s

mkfs.ext4 dummyfile

mke2fs 1.42.5 (29-Jul-2012)
dummyfile is not a block special device.
Proceed anyway? (y,n) y
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
10240 inodes, 40960 blocks
2048 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=41943040
5 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
    8193, 24577
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

mkdir testmount

mount -o loop dummyfile ./testmount/

df -PTah testmount/

Filesystem Type Size Used Avail Use% Mounted on
/dev/loop0 ext4 39M 4.5M 33M 13% /mnt/testmount

touch /mnt/testmount/x

chmod +t testmount

su - username

$ cd /mnt/testmount
$ ls -lart
total 17
drwx------ 2 root root 12288 Mar 29 04:42 lost+found
-rw-r--r-- 1 root root 0 Mar 29 04:43 x
drwxr-xr-t 3 root root 1024 Mar 29 04:48 .
drwxr-xr-x 3 root root 4096 Mar 29 04:48 ..

$ rm x
rm: remove write-protected regular empty file x'? y
rm: cannot remove
x': Permission denied

?????
Mar 29, 2016 at 8:36 AM
The final reply is beyond me. I don't understand. Maybe it's for programmers?
Mar 29, 2016 at 12:30 PM
Sorry, but those are steps to prove sticky bit works.... the file x could have been a VC container. It was placed in to a mount point of a dummy file that had an ext4 file system created within it. That dummyfile, for all intents and purposes is just like your external hard disk -- only smaller.

This whole discussion has gone way off topic for the thread. Furthermore, I don't think it is VC's job to worry about what a user does to files that he/she can manipulate outside of VC (or even within VC when it is mounted). Responsibility for those files lies with the user.
Apr 7, 2016 at 5:10 AM
Edited Apr 7, 2016 at 5:11 AM
I solved my problem!! I wish to share my experience for other users. Creating an undeleteable folder on a usb HD.

Step 1 Create an unallocated space with gparted (resizing HD). One can format it and label it too.
Step 2 Create an encrypted container in a hard drive as root and follow instructions.
when finished, make sure to change proprieties to user (not root)

Nobody can delete the folder except when in root.