VeraCrypt Review

It works!  I recently switched to VeraCrypt from TrueCrypt, because TrueCrypt is now unsupported and rumor has it that technology was making TrueCrypt less and less secure.  I do not use Partition/Device encryption or System encryption, only Volume Encryption, meaning that specially-created "container" files in the normal unencrypted Windows environment are mounted as encrypted volumes exactly as if they were separate, encrypted disk drives.  I keep my personal and business files there, and I do it this way because it is simple, because backup of those container files is trivially easy, and because there is zero risk of a complete failure.

If you want to know more about Partition/Device encryption or System encryption, the information in this post may not help you.

A year ago I wrote about TrueCrypt Forks. I didn't like VeraCrypt then because it took a very long time, a minute or more, to open a container after entering the correct password.  This was by design - the VeraCrypt developer, Idrassi, by default uses hundreds of thousands of iterations in the key derivation function, contending that it helps protect against brute-force attacks, where a computer is automatically trying billions of password guesses.  He is right - this method of attack is becoming faster and more effective as computer power increases and multiple processors can be brought to bear.  However, I open and close encrypted volumes frequently and the defaults pushed my patience too far.

Happily, the current version of VeraCrypt, Release 1.17, offers a compromise:  If the password is 20 characters or more, VeraCrypt allows the user to bypass the defaults and choose a lower number of iterations by specifying a Personal Iteration Multiplier (PIM).  The minimum multiplier of 1 will still result in an iteration count 8 to 16 times greater than that used in TrueCrypt, with a very short delay, whereas multipliers in the range of 10 to 100 will increase security but will cause somewhat greater delays.  Those delays might still be acceptable, depending on the speed of the processor. I experimented with several different PIM values.

The PIM is a secret value, chosen when the container file is created, and it must be entered correctly as a separate parameter when the password is entered to mount an encrypted volume.  Therefore, though the PIM may be used to reduce the iteration count and make a brute force attack easier, it also effectively increases the password strength, making the attack more difficult again.

I use passwords of 20 characters or more anyway, so the PIM is a perfect compromise.  During the process of creating new volumes I did have to wait through some long delays, but now that the volumes are created and in place, the delays are quite acceptable.  PIM works.

Also interesting, VeraCrypt can actively coexist with TrueCrypt on the same system, running at the same time.  I created new VeraCrypt containers and copied the encrypted contents of the old mounted TrueCrypt volumes directly into the mounted VeraCrypt volumes with no problems.  During that process, none of the encrypted files were ever decrypted on disk.  That's cool - no disk wiping required.  Actually, VeraCrypt can mount most TrueCrypt volumes (though not my oldest ones), so the applications might not have to coexist, but it was slick.

I rarely use the TrueCrypt or VeraCrypt console, instead using command-line scripts (cmd.exe processor) to automatically mount and dismount volumes, create backups of volumes, copy volumes to the cloud and to other computers, and more.  Every script that worked with TrueCrypt still works with VeraCrypt, after just changing the run path.  It just works, no errors, no problems.

For a thorough, functional test I uploaded a 3 GB encrypted container full of files to the cloud, using both iDrive and CloudBerry, then downloaded that same file back to the desktop.  Using Microsoft's comp program, the files compared exactly with the original in each case.  Also, in each case, the downloaded encrypted container opened without issue, the true proof that the file was not corrupted.

I use VeraCrypt on two computers, a desktop and a laptop,  The desktop runs a clean install of Windows 10 (it once ran Vista), and the laptop runs Windows 10 upgraded from Windows 7.  Both have plenty of RAM and disk, with dual processors in the 2 - 3 GHz range.

My congratulations to Mounir Idrassi, the force behind VeraCrypt.  I'll be making a PayPal donation to the cause.

By the way:  I also downloaded CipherShed, intending to compare it with VeraCrypt.  However, the CipherShed installer informed me that I would have to uninstall TrueCrypt first.  Since I want to keep TrueCrypt around, I did not install CipherShed.

Cloud Backup Review, IDrive vs Cloudberry

My desktop running Windows Vista Ultimate is already backed up thoroughly by a command-line script that I start every night when I go to sleep.  The script shuts down certain processes (e.g. FTP server, open TrueCrypt volumes, KeePass password vault) and copies all important files to other local hard disks.  

I also need a cloud backup, though, in case of a disaster like a fire, flood, theft, vandalism, sinkhole, asteroid, apocalypse, whatever, because all of my hard disks are in the same building.  A close friend did have a fire and lost everything. What the fire doesn't get, the filthy, soaking, ash-filled water does.  In my view everyone needs a cloud backup these days, and maybe it's the other local disks that are unnecessarily redundant.  I have 62,000 files to upload, totaling 7+ GB, including a 3GB TrueCrypt volume file.

Because I already have a time-tested command line backup script, I want my cloud backup to fit in and be part of it. At the least, the script should be able to start the cloud backup from the command line, know when it's done, and preferably log any errors that occur.  Then, when the cloud backup is done, the script can perhaps do other cleanup tasks and shut down the computer, or put it to sleep, or get going on other things that it needs to do.

At least two cloud backup offerings seem to have a sufficiently robust command-line interface and with "chunk" backup capabilities (more later): IDrive and CloudBerry.

IDrive is a complete backup solution, offering an installed application program, a web-based interface, a command-line interface, and storage.  Backups are physically kept on IDrive's own web servers.  The Basic Plan is FREE, with 5 GB file storage space and another 5 GB of "sync" space (files kept automatically in sync.).  You can also get "credits" for referring IDrive to others.  


I did that and used the free plan for my 7 GB for a whole year, before something failed and I needed help.  Since then I have upgraded to IDrive Personal, with 1000 GB of storage, which cost me $39.95 for the first year.  That's not expensive, and it's my impression that cloud backup prices are going down, so I doubt that cost will go up much.

Features important to me:

• Incremental backup is standard, of course.  Only new or updated files are sent to the cloud.
• "Chunk" backup for large files allows backup of only the parts of the file that have changed.  Automatic in IDrive.
• Command line interface.
• Data transmission and file storage are both encrypted.

Concerns:

• The IDrive Application program failed this month, and I was unable to get it going again without help.  The online chat support did the trick, but the technician went so fast that I was unable to see what s/he did.  I believe that s/he changed permissions in c:\Program Files (x86)\IDriveWindows and c:\ProgramData\IDrive, then did something with the VSS Service.  I asked the tech what s/he did, and got an answer like "fixed your computer," for which s/he gets a "D" for customer communication.  My concern is that it may fail again after some Microsoft update.
• The command line interface utility that comes with the newest IDrive download doesn't work on Windows.  Log in fails.  I use an older one that does work.
• For file encryption, you get a choice of a default key or a private key.  A year ago I chose the default, but suddenly this month the program demanded my private key.  Since I didn't have one, my data was lost and I had to upload the whole 7 GB again.  Now I do have a private key, but will it always work?

Validation:  After the most-recent backup I downloaded the 3GB Truecrypt container file and compared it bit-by-bit with the original here, using the comp utility.  There were no differences.  Further, I was able to open that downloaded file with TrueCrypt, highly unlikely if the file was corrupted at all.

CloudBerry is a front end application program for use with any number of cloud storage space vendors.  Its most robust implementation, though, is with Amazon S3 storage, and that is how I am using it because I need some features only available with Amazon S3.  For desktop (or laptop) use, there is a Freeware version called CloudBerry Explorer which does have some command line functionality, but I don't know how much, and I don't know if it handles "chunks."

I am have just purchased CloudBerry Backup (for Windows Desktop), a "Pro" version, for $29.99 plus $6.00 for an annual update service.  I'm happy to pay that. The Amazon S3 storage cost is trivial for my 7 GB:  The first 5 GB is free for 12 months, and prices thereafter are 3 cents per GB per month, at most. That will be $0.21 per month, or less than $3.00 per year. There are also transaction fees (for GET and PUT requests).  In this first month my Amazon S3 bill is so far $0.34 (34 cents), most of which is transaction fees for the initial upload of files.  I'll be happy to pay the Amazon costs too.

Features important to me:

• Incremental backup is standard, as with IDrive.  Only new or updated files are sent to the cloud unless a full backup is specifically ordered.
• "Chunk" backup of huge files is available with Amazon S3, and it is possible to configure the size of the chunks.
• Command line interface.
• Data transmission and file storage can both be encrypted.

Concerns:

• Amazon S3 is complicated, and you have to sign up for that separately.  I recommend sticking with as many defaults as possible.  I tried Google Cloud too, and it is simpler, but fewer features are available.
• The CloudBerry command line interface CBB.exe has many, many commands, a confusing array in fact.  Further, when starting a backup with a pre-existing backup plan, CBB simply starts another program, CBBackupPlan, and then quits, so the batch script can only know when the actual backup is done by looping, waiting for CBBackupPlan to disappear.  I'll be happy to supply that code or the whole script if anyone wants it.  It's all in CMD command line language.
• When performing a backup, the progress reports on the screen are mostly nonsensical.  It pulls up a list of 1000 files are a time, and sort of tells you how it's doing with that 1000. The Overall Progress bar shows about 33% most of the time, for some reason.  The backup works, so it doesn't really matter, and it does show a count of files uploaded, so if you know how many there are, you can figure progress yourself. 

Validation:  I have several times downloaded the 3GB Truecrypt file and compared it with the original from my computer. There were no differences.  Further, I was able to open that downloaded file with TrueCrypt, highly unlikely if the file was corrupted at all.

Some speed comparisons:

First, I am using a DSL connection to the internet, with 26Mbps download and about 0.9Mbps upload.  

• For both CloudBerry and IDrive, the upload time for my full 7GB is almost a day. I hope not to do a full backup very often!
• I have one 3GB encrypted file which downloads in 21 minutes with CloudBerry and 71 minutes with IDrive. Big difference.
• Smaller files download in no time, of course, and both providers make file selection and destination selection easy.
• Daily incremental backups take about 9 minutes with CloudBerry and 21 minutes with IDrive. Also a big difference, but I'm asleep anyway.

A SERIOUS CAUTION ABOUT CLOUD BACKUP:  If you end up needing it, you will be required to supply passwords.  In the case of Cloudberry, for example, you may need a password to access the CloudBerry program on a new computer, and if you use Amazon S3 services for storage, CloudBerry will ask you for a lot of information.  You will need your Access Key ID (long), your Secret Access Key (longer yet), the Encryption Password, and possibly the name of your Amazon S3 Bucket.  

For any other storage provider you will need similar information.  For IDrive you need at least the IDrive Password, and also the Private Encryption Key if you have chosen your own.

Obviously, it's no good backing that stuff up on the cloud with everything else!  It's inaccessible.  These passwords and keys will not change often, and you should have them offsite, far away from your computers.  I keep mine on a gold archival DVD in a safe deposit box.  A thumb drive might be more convenient in the future, but there are folks who believe that thumb drives are not a good archival medium.  My next computer will have a Blu-Ray (and DVD/CD) drive anyway. But I might keep a thumb drive in the safe box too, as backup.  :-)

Just sayin'