SoylentNews is people
SoylentNews
VeraCrypt security audit reveals many flaws, some already patched [Zeljka Zorz/Helpnet Security]
VeraCrypt, the free, open source disk encryption software based on TrueCrypt, has been audited by experts from cybersecurity company Quarkslab.
The researchers found 8 critical, 3 medium, and 15 low-severity vulnerabilities, and some of them have already been addressed in version 1.19 of the software, which was released on the same day as the audit report.
The code auditing effort analyzed VeraCrypt 1.18 and its bootloaders.
"A first step consisted in verifying that the problems and vulnerabilities identified by iSec and NCC Group in TrueCrypt 7.1a for the Open Crypto Audit Project had been taken into account and fixed," the Quarkslab researchers involved in the effort explained.
"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."
A short overview of the issues found (fixed and still not fixed) can be found here. The audit report, with mitigations for still unpatched vulnerabilities, can be downloaded from here.
Are any Soylentils using Veracrypt and/or other forks of Trucrypt?
The full audit report: TrueCrypt Cryptographic Review[PDF] [Alex Balducci, Sean Devlin, Tom Ritter/Open Crypto Audit Project]
Previously:
Independent Audit: Newly Found TrueCrypt Flaw Allows Full System Compromise
No Backdoors Found in TrueCrypt
TrueCrypt Site Encodes Warning about NSA Infiltration
TrueCrypt Discontinued, Compromised?
-- submitted from IRC
(Score: 5, Informative) by Post-Nihilist on Tuesday October 25 2016, @10:43PM
Problem:
The availability of GOST 28147-89, a symmetric block cipher with a 64-bit block size, is an issue. This algorithm has been added in VeraCrypt 1.18. It is a 64-bit block cipher, contrary to the other block ciphers used in VeraCrypt. The XTS code has not been adapted for such ciphers, so VeraCrypt emulates a 128-bit block cipher by encrypting two 64-bit blocks in CBC mode with a zero IV, which in itself raises several issues. Furthermore, to reach the same level of security as its 128-bit counterpart, the amount of data to be processed should be no more than 512 bytes which is too small to be considered for a data at rest encryption system. GOST 28147-89 will be removed in version 1.19.
Mitigation: do not use GOST 28147-89
Problem:
If the system is encrypted, the boot password (in UEFI mode) or its length (in legacy mode) could be retrieved by an attacker.
Mitigation: use a long password and avoid UEFI.
Problem:
Vulnerabilities which require substantial modifications of the code or the architecture of the project have not been fixed. These include the AES implementation, which is still susceptible to cache-timing attacks.
Mitigation: replace AES with Camellia
Be like us, be different, be a nihilist!!!
(Score: 3, Interesting) by Runaway1956 on Wednesday October 26 2016, @12:40AM
So, essentially, Veracrypt is the best thing on the market, IF you understand those three vulnerabilities and their "fixes"?
And, even if you don't know to avoid GOST, and to use a long password, to avoid UEFI, and to use Camellia - Veracrypt is still pretty good?
These vulnerabilities have been identified, but there seems to be no indication that they are being exploited - yet.
I'm going to buy my defensive radar from Temu, just like Venezuela!
(Score: 3, Interesting) by Post-Nihilist on Wednesday October 26 2016, @02:07AM
GOST 28147-89 is for Russian fetishist.
If you do not know how to use long password Veracrypt is not for you
And cache timing attack are somewhat impraticables.
if you have a need to encrypt a volumes and you do not have the ressources of a nation state then yes veracrypt is still pretty good
And I felt trolled
Be like us, be different, be a nihilist!!!
(Score: 3, Informative) by driverless on Wednesday October 26 2016, @10:36AM
These include the AES implementation, which is still susceptible to cache-timing attacks.
Mitigation: replace AES with Camellia
So in order to carry out this attack you need to have an attacker's hostile software running with root privs, or close to it, on the CPU doing the disk encryption. Mitigation: Not a real attack, nothing to mitigate.
(Also, how do you know the Camellia implementation is any better?).
(Score: 2) by Post-Nihilist on Wednesday October 26 2016, @09:19PM
Your right, Camellia has the potential to be worse
Be like us, be different, be a nihilist!!!
(Score: 2) by Post-Nihilist on Wednesday October 26 2016, @09:23PM
I missed that phrase : "NCC Group’s report only focuses on AES. We did not check if other implementations are
susceptible to such attacks" when I first read the report, I apologize
Be like us, be different, be a nihilist!!!
(Score: 3, Informative) by Fnord666 on Tuesday October 25 2016, @10:58PM
(Score: 2, Informative) by Anonymous Coward on Wednesday October 26 2016, @03:25AM
Yes Truecrypt has vulnerabilities but many of them do not apply for the "non-shared machine" scenario. If you are using disk encryption and you are sharing the machine live with other users (e.g. attackers have already pwned you) then you are doing it wrong.
Item: "Weak Volume Header Key Derivation Algorithm"
Use a passphrase just a few characters longer and you'd achieve the same thing as going from 1000 round PBKDF2[1] to a million rounds.
Item: "Cache timing"
"The only attack scenario where it would be possible to take advantage of a cache-timing is the case of physical machine hosting two virtual machines, one with a system entirely encrypted and the other controlled by an attacker."
If the attacker has enough access and smarts to pwn you or your data in that scenario you are probably pwned by the attacker already through other easier ways.
Item:"Multiple Issues in the Bootloader Decompressor"
How is this a real problem?
Item: "Sensitive Information Might Be Paged Out from Kernel Stacks"
This is a problem but possible workarounds are to not enable paging, or to only page to encrypted drives.
[1] if you want to fuck with those trying to brute force your stuff, what you can do is hash the passphrase then use the results to help determine the rounds for PBKDF2 (e.g. rounds= 2000+ (sha256(passphrase) mod 1000 ) ). It'll be fun to see them build ASICs to handle that.
(Score: 0, Interesting) by Anonymous Coward on Wednesday October 26 2016, @12:01PM
It's not clear to me whether these vulnerabilities are in features added since the Truecrypt fork, or if they're bugs in code inherited from Truecrypt itself.
IIRC, the audit/s that Truecrypt underwent were only of specific subsystems, and not as thorough as this one.
(Score: 0) by Anonymous Coward on Wednesday October 26 2016, @06:44PM
That's because you didn't read one of the links supplied: http://blog.quarkslab.com/security-assessment-of-veracrypt-fixes-and-evolutions-from-truecrypt.html [quarkslab.com]
Among the problems found during the audit, some must be corrected quickly:
The availability of GOST 28147-89, a symmetric block cipher with a 64-bit block size, is an issue. This algorithm has been added in VeraCrypt 1.18. It is a 64-bit block cipher, contrary to the other block ciphers used in VeraCrypt. The XTS code has not been adapted for such ciphers, so VeraCrypt emulates a 128-bit block cipher by encrypting two 64-bit blocks in CBC mode with a zero IV, which in itself raises several issues. Furthermore, to reach the same level of security as its 128-bit counterpart, the amount of data to be processed should be no more than 512 bytes which is too small to be considered for a data at rest encryption system. GOST 28147-89 will be removed in version 1.19.
(Score: 0) by Anonymous Coward on Wednesday October 26 2016, @01:33PM
I have a client using TrueCrypt still. They are using the last released version; we saved the binaries in various places. They are in a very confidential business and were concerned following public data leaks that something like that could happen to them. The company partners didn't want to trust Microsoft to not have golden keys for their encryption scheme someone could steal; they felt if someone stole MS's keys, MS would be good at covering it up, and we wouldn't know until years later, well after their business was ruined by a data leak.
I wanted to change them to VeraCrypt, but it's installed on around 100 PCs, and the users are not very technically literate. There was a concern about retraining them if the screen didn't look exactly identical on each machine they might need to use. Probably won't be able to upgrade them to a new setup until the next major company-wide upgrade.
I do wonder about the real effectiveness of the encryption in the event that a machine was actually stolen as they fear.
(Score: 2) by tangomargarine on Wednesday October 26 2016, @02:14PM
I have a client using TrueCrypt still. They are using the last released version
Technically they're probably using the second-to-last version, since the last build they released concurrent with their closing the project only allows you to read volumes, but not write to them.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2, Insightful) by Francis on Wednesday October 26 2016, @02:31PM
In other words, they're idiots that have been coddled.
It's rather unfortunate, that IT winds up having to babysit people that are too lazy to learn anything. A simple one page document should be more than enough to get people to switch to a new program like this. The security implications of a new program really ought to be a bigger concern than the users.
Now, if this were a replacement for a complicated piece of software like Office, I could completely understand it, but at some point people need to just accept that they need to actually learn how to use computers. The last thing we need is for another generation of folks to think it's OK to be bad with computers. It's bad enough that we have people thinking it's OK to be bad at math when they aren't even trying to do math. At least those consequences tend to not affect others.
(Score: 2) by lgw on Wednesday October 26 2016, @08:11PM
I've yet to see any practical exploits in TrueCrypt that are fixed in VeraCrypt. Why would you insist people change? Until we have real evidence that VeraCrypt is making the overall security better than TrueCrypt, what's the win, and what's the urgency?
I begin to suspect you're an IT guy of the tier who still thinks changing passwords every 90 days is a good idea.
(Score: 1) by Francis on Thursday October 27 2016, @12:18AM
Because Truecrypt is known to have exploits, we still don't know why they suddenly abandoned it and the developers of Veracrypt appear to be taking things seriously and were cooperating with the audit. I'm sure they'll fix whatever the audit before too long.
OTOH, at some point you do have to make the switch, given the highly unusual way in which Truecrypt ended it's existence, I wouldn't personally trust it further than I could throw the developers. I don't use Veracrypt either, but I haven't used Truecrypt a single time since the project was shuttered other than to remove my files from it.
What's more, the security of the software is usually less of a problem than the security of the users and if they're so dense that IT was worried about them making this transition, that doesn't speak well about them.
(Score: 2) by lgw on Friday October 28 2016, @12:36AM
Because Truecrypt is known to have exploits
What practical exploits is Truecrypt known to have? The audit didn't find any, beyond "short passwords aren't safe".
OTOH, at some point you do have to make the switch, given the highly unusual way in which Truecrypt ended it's existence
I trust audits over speculation. I believe the devs ended the project to prevent exploits being added, when pressure was brought to bear on one of them by a government. It's certainly possible that it has an exploit no one found yet, and the government pressured a dev to keep it secret, but that's possible with any tool, so what can we trust beyond audits (and hope they aren't also compromised)?
(Score: 1) by Francis on Friday October 28 2016, @02:36PM
How quaint, you've still got faith in humanity.
The truth here is that we don't know why they up and stopped development suddenly. I can't think of any other projects like this that were abandoned so quickly with no explanation or signs ahead of time. It is speculation, but it's certainly a safer speculation than your far less likely view that there's an exploit that the government wanted kept secret.
Ultimately, do what you want, but it's ridiculous to use questionable encryption technology under this sort of circumstance. The Veracrypt folks will fix those bugs and do you really want to be the one whose stuff gets broken into because somebody made one of those impractical exploits practical?
Also, read the audit, but if the data is worth encrypting, then it's worth encrypting with something secure and supported.
(Score: 2) by lgw on Saturday October 29 2016, @12:56AM
Fundamentally, I don't trust the Veracrypt guys yet.