Hi, Is there a common understanding in this group regarding the level of trust one can put into Veracrypt as compared to its predecessor, Truecrypt? I am particularly thinking about the probability of backdoors. I just came from the thread about VPNs where s.o. wrote you cannot expect corporations to not cooperate with the authorities to turn over logs. Since Veracrypt is developed by a corporation too, shouldn't it be expected that they got pushed into putting a backdoor into Veracrypt? Any thoughts on this? Tom
Well software is open source so everyone (who knows how) can check and see if there are backdoors included. As I remember they also had some audit of code in past and as I can remember vulnerabilities that were found were also fixed. They also fixed problems found during TrueCrypt audit.
Who's to say TrueCrypt was trustworthy? I still find it questionable that it was abandoned during the audit. I'd use VeraCrypt with as much confidence as TrueCrypt. Take that any way you would like.
My guess is that anyone who develops popular, effective encryption software will be approached by the Feds for backdoors sooner or later. My assumption is also that a corporation has a larger attack surface than a group of anonymous hackers (and is easier to address in the first place). But I am guessing and that's why I want my guesses to be challenged by more educated ones ;-)
They would have to hide backdoor well, since software is open source. Otherwise others could use same backdoors also once that information gets out. More likely LEAs would promote less secure encryption than "traditional" backdoor that would be noticed easily.
When I say "backdoor", do not think "hardcoded pswd"; instead think "subtle security bug ". Array bounds not checked is too clumsy; think of Meltdown/Spectre; a comma instead of a semicolon... And yes, one day someone might find and exploit it. That's exactly my concern.
The view I've always taken is that if you use a good long strong passcode (not as easy as it sounds), that makes the crypto hard to break regardless. For instance, there were weaknesses identified in the TC audit, and subsequently improved in VC. But they can be adequately mitigated if you have a good password. And that "they" are much more likely to attack other things than the crypto beyond that point, which ranges from attacking the software distribution, the client endpoints, or the client (with a wrench!).
The subtle risk with both of these software products is the "build". If I send or publish perfect open source code you will determine upon examination that it is secure. BUT if I then BUILD/circulate a binary from a modified version of that code, almost nobody can disassemble it with certainty to detect the changes made. TC was nearly impossible to build and have the exact same hash value as the publicly circulated binary. That meant that a small deviation could NOT be flagged as edited code but rather written off to other nuances from the build. VC is much the same EXCEPT the linux version builds well and much easier. If you really have your A** on the line for security it would be a good idea to learn to do your own builds from established and verified source code. If you are not using linux the notion of worrying over security seems to belong on the OS and not VC/TC primarily. My .02
Indeed, and also very much worth avoiding either common phrases/quotes (whether in full or abbreviated), and likewise anything that can be found in your personal records and emails. I personally take comfort in physical dice in a technology-free zone!
This point seems to always get lost when discussing this or that crypto software. If, for example, Microsoft decided to add code to Windows that recognized TC,VC, etc... and plucked the volume master key from memory, encrypted it and buried it in the registry, who would know?
Which is also why, if you only want commercial level security, Bitlocker on Windows is a reasonable solution. The FDE is the least of your worries if you want more assurance. I think this is all part of the crypto run-round, subversion of the client computer or client themselves is easier.
I guess the assumption there is that the installers they distribute are actually built from the published source code.
Yes, that's assumption, like with most open source software. Off course, if users can compile software by themselves, they don't have to use official installer.