VeraCrypt 1.19 fixes security vulnerabilities
VeraCrypt 1.19 is the newest version of the popular open source data encryption program that many users switched to after TrueCrypt was discontinued back in 2014.
The application is based on TrueCrypt code but has since then been updated regularly with new features, improvements and most notable security fixes.
The VeraCrypt team fixed security vulnerabilities that a TrueCrypt audit brought to light, and has fixed several vulnerabilities or issues since then.
The team announced back in August 2016 that VeraCrypt would receive a security audit of its own thanks to the Open Source Technology Improvement fund.
The scope of the audit was twofold. First, to verify that TrueCrypt related issues are fixed, and second, that features introduced by VeraCrypt did not introduce issues of their own.
A first step consisted in verifying that the problems and vulnerabilities identified in TrueCrypt 7.1a had been taken into account and fixed.
Then, the remaining study was to identify potential security problems in the code specific
to VeraCrypt. Contrary to other TrueCrypt forks, the goal of VeraCrypt is not only to fix
the public vulnerabilities of TrueCrypt, but also to bring new features to the software.
VeraCrypt 1.19
The security audit of VeraCrypt and its bootloaders by QuarksLab has been completed. The company found a total of 26 different vulnerabilities or issues of which eight were rated critically. The remaining vulnerabilities received a rating of medium (3) and low or informational (15).
VeraCrypt released version 1.19 of the encryption software that addresses the majority of issues found by QuarksLab. This includes among others a fix that protects against the leaking of the password length in the MBR bootloader inherited from TrueCrypt on Windows machines.
The technical documentation of the audit reveals that some vulnerabilities have not been fixed yet because of their complexity as they require either major modifications to existing code or the project architecture.
This includes for instance a problem with the AES implementation which makes it susceptible for cache-timing attacks. The only way to resolve the issue is to rewrite the AES implementation which takes time.
The release brings other improvements, for instance a 2.5 times performance increase of the Serpent algorithm on 64-bit systems, EFI system encryption support on 32-bit versions of Windows, and a fix for EFS data access issues on Windows 10.
The documentation has been updated to inform users about potential security issues. See the tokenpin command line parameter for instance as an example.
VeraCrypt users who are interested in the audit find the technical report here (pdf document). The release notes of the new version are posted on the official VeraCrypt project website.
Closing Words
VeraCrypt security has improved significantly thanks to the audit. While there is still work that needs to be done to address the issues that are too complex to be fixed in a short period of time.
Since it is one of the few remaining TrueCrypt forks or successor projects that is still updated regularly, it may be a good idea to migrate to it if that has not been done already.
Now You: Do you use an encryption software? If so which and why?
VeraCrypt 1.20 beta2+ now supports fully UEFI/GPT (except hidden/recovery partitions) so that you can encrypt entire OS, just tested it and it works well.
Only thing I found is that you need on a cold boot, boot into recovery/repair mode (will be done automatically) and boot from USB with the efi/veracrypt file/folder and then it boots the veracrypt OS partition. So the recommended steps for now are to disable FastBoot or try to boot via F12 to select the partition (if available).
https://sourceforge.net/p/veracrypt/discussion/technical/thread/5b859040/?page=1
https://security.stackexchange.com/questions/138333/veracrypt-windows-boots-automated-repair-on-uefi-gpt
Good news, great. Thanks for your report, will give it a try.
I use VC and have had no issues with it at all. I don’t use system encryption though. I have used TrueCrypt for system enc. in the past. Now I don’t encrypt my system but move my data libraries into another partition which I mount at bootup.
One question. Is it enough to update from 1.18 to 1.19 or is there something I have to do with the encrypted file/volume ?
If you have system encryption, then it ought to have updated your bootloader to fix one of the critical bugs. If not, then you have to decrypt then re-encrypt the system drive to ensure the bootloader is fixed.
For your containers/volumes, it depends. Are you expecting the Feebs to want to access it, or just thieves or nosy spouses? Are these encrypted on a PC that supports AES-NI (search Wikipedia for that term to find which processors have it)? I still have a couple of encrypted external HDDs from Truecrypt that were made before I got a processor with AES-NI. Indeed, when I first heard of AES-NI, it became a no-compromise requirement when I upgraded my PC. I see no reason to re-encrypt them even though they’re susceptible to the cache-timing attack. It is an expensive attack with a small chance of success, and at best the attacker will only find out my predilection for Japanese ecchi anime. All of the rest are encrypted post AES-NI and so are safe from that bug.
If you are hiding something you don’t want state actors to access, then yes maybe you should re-encrypt everything. If not, then you’re pretty safe. No one’s gonna spend millions of dollars to do cache timing attacks against your data unless you have something they really want. And they’ll probably just use rubber hose cryptanalysis.
I’ve had bud luck with Veracrypt. Volume corruption and general system instabilities.
I’ve been using TrueCrypt for many many years and swapped everything over to VeraCrypt about a year back. The security implications do not bother me as I only use encryption for personal stuff if a laptop or tablet it lost or stolen.
It seems trivial nowadays for three letter agencies to crack modern encryption so why fret over extreme security. As long as Johnny the Thief down the road doesn’t get our bank account access, that is good enough for me.
I will certainly update our 1.8 to 1.9, but I suggest that if you (@Ben) feel the need for extreme security to worry about auditing chains for VC or even TC, then probably neither (VC otr TC) is going to be strong enough for you. And, you certainly wouldn’t and shouldn’t be asking those questions here as it suggests concern for vulnerability. With all security, the fewer people who know you use it the better.
I also use encryption to make sure that thieves don’t access my laptop contents (which may contain, ahem, privately filmed erotic videos).
But contrary to your belief, three letter agencies can’t attack modern encryption directly. The math works. But these agencies don’t attack the encryption, they attack the implementation. They can’t attack AES, it is still rock solid. But bad implementation of AES by Truecrypt and Veracrypt have made it vulnerable to cache timing attacks. Gost is a decent Russian cipher than can withstand brute force attacks by the NSA. But it was so badly implemented in VC (which was not implemented in TC) that it can be open to attack.
If the NSA has the hots for me, there is nothing I can do to stop them. They can’t access my AES encrypted laptop, but they don’t have to. They can surveil all of my online activities, access my google account, read my gmail, even plant an APT in my pc. And they can surely listen to my conversations over the phone. But if we all use encryption, it will at least make passive surveillance harder.
I’ve read the technical notes of the audit and have updated to version 1.19. For the cache-timing attack, it will only affect you if you created encrypted volumes in a PC without AES-NI, or you deliberately chose to disable use of the AES-NI in veracrypt out of a misguided notion of better security. Without the said instruction set, VC will downgrade to using the mentioned vulnerable AES software libraries. Since I use AES-NI and have created all of my recent volumes on a modern chip with that instruction set, I am not affected by this vulnerability.
Further, they have rehashed the argument about the uselessness of keyfiles in cryptographic security. I have previously read the notes written by the Ubuntu team, and I still think that the Truecrypt developer’s response is apt. If the attacker does not know if you use keyfiles, and how many keyfiles you use, and especially what keyfiles you use, then he is in no better position to attack your PBKDF2 generated crypto-key. Any scenario the auditors have made to weaken the use of keyfiles, still shows that it is better than using the password alone. It won’t make your security worse, and it may make it better. That, for me, is enough reason to keep on using keyfiles with passwords.
Is there a verifyable chain from the latest (real) TC source up to the source of VC now?
Can I get each patch separately?
Anyone maybe wrote a blog post on that?
No one’s going to do your homework for you. If you want verifiability, why rely on Martin or any other blogger’s word? Download the source codes for both and compare it yourself.
Answering three questions by only (semi-)answering the last one is not really helpful ;)