
VeraCrypt to be audited - kobayashi
https://ostif.org/we-have-come-to-an-agreement-to-get-veracrypt-audited/
======
akerro
And the very next post on their blog says:

OSTIF, QuarksLab, and VeraCrypt E-mails are Being Intercepted

We have now had a total of four email messages disappear without a trace,
stemming from multiple independent senders. Not only have the emails not
arrived, but there is no trace of the emails in our “sent” folders. In the
case of OSTIF, this is the Google Apps business version of Gmail where these
sent emails have disappeared.

[https://ostif.org/ostif-quarklab-and-veracrypt-e-mails-
are-b...](https://ostif.org/ostif-quarklab-and-veracrypt-e-mails-are-being-
intercepted/)

~~~
Tomte
That would be an incredibly inept and stupid interception operation.

OTOH, mails disappearing is not exactly uncommon.

I call bullshit.

~~~
jrochkind1
Inept malware happens, but yeah, i'm not sure I'd expect inept malware in an
email intercept operation.

I once helped someone diagnose a 'broken' WordPress operation. It had
unpatched vulnerabilities, and had been infected with malware that appeared to
make it click on ads somewhere or other, from what I could tell. But the only
reason it was even discovered is it also brought down their site with a syntax
error in a *.php file. If they had kept the site up and running, the owners
probably never would have noticed that their WordPress installation was
periodically simulating clicks on ads in the background.

------
micaksica
As a VeraCrypt user, I'm in support of this type of thing happening more for
potentially critical open-source projects like this.

It'd be pretty cool if larger security consultancies with cryptographic
expertise would band together and come up with a way to easily work with these
types of projects, that way they could crowdfund exactly what they'd need to
complete audits like this for themselves. I'd give a good chunk of change to
projects that I used if they had a crowdfunding page for their cryptographic
audit efforts that didn't expire ever.

~~~
nxzero
>> "I'd give a good chunk of change to projects that I used if they had a
crowdfunding page for their cryptographic audit efforts that didn't expire
ever."

What in USD is a good chuck of change? What projects?

Think for example I asked Moxie about doing something like is for Signal, and
as far as I recall the response was that it's open source.

------
yeukhon
One-time audit is great, but continuous auditing is also crucial. There are
three kinds of vulnerabilities I can think of:

* software bugs

* design flaw

* backdoor

First could be detected using fuzzer, static analysis and proof reader.

The second and third, unclear to me how could be found intelligently without
human code review. Perhaps
[https://news.ycombinator.com/item?id=12236394](https://news.ycombinator.com/item?id=12236394)
is relevant? Anyone?

~~~
wepple
> First could be detected using fuzzer, static analysis and proof reader.

I respectfully disagree; I don't think we're truly at the point where we can
rely upon these techniques over human code review.

~~~
bluGill
If you are relying on anything alone you are a fool. If you are not using the
above as part of your solution you are a fool.

Each of the above will consistently find certain types of errors. The above
tools do not "let their mind wonder", get bored, or any of the other things
that happen to humans.

When you as a human find an error it is worth asking if you can modify one of
the above tools to find that class of errors so that you can be sure all cases
were caught. Unfortunately most of the time we cannot yet (generally because
the number of false positives is too high - I'm hoping for research to improve
this)

~~~
wepple
I agree with everything you've said. Automation and tooling where it excels,
humans where necessary and for oversight.

My comment was largely around the fact that parent comment seemed to say
"software bugs have been solved by tools, but design problems need humans". I
think design/backdoor/crypto bugs may be more (or entirely) depending on
manual audit, but it's dangerous to suggest software bugs can be fully
automated away.

Perhaps the parent comment was suggesting we should look to more software
solutions to backdoor/design flaws? that's an interesting thought exercise.

------
coroutines
As a Lehman... the only thing I don't like about Veracrypt is it seems to have
a different on-disk container format than the original Truecrypt. I don't like
having to remember to check "Truecrypt compatibility mode" when unlocking a
drive. I only use the Truecrypt format because so many other tools exist (like
tcplay) and because dm-crypt supports that format natively. If Veracrypt does
take over the community of those who used Truecrypt, I hope its format gets
supported upstream so we'd be at the same level of cross-platform portability.
(really I'm only talking about what I had previously on Linux, though)

------
DINKDINK
They VeraCrypt developer claims to have fixed several weaknesses in the
TrueCrypt codebase in this interview:
[https://www.youtube.com/watch?v=rgjsDS4ynq8](https://www.youtube.com/watch?v=rgjsDS4ynq8)

Will be interesting to follow the audit.

~~~
unixhero
Anyone know if those fixes has flow back to the Linux kernel implementation of
True Crypt (tcplay / LUKS)?

~~~
mhogomchungu
"dm-crypt" is the infrastructure in the linux kernel that deals with block
device encryption.

TrueCrypt,VeraCrypt,zuluCrypt,tcplay,cryptsetup among others use this
infrastructure to do user data encryption/decryption.

What these project do is parse a volume header on a volume to get crypto
properties and then pass them to dm-crypt for it to do everything else.

The difference between a TrueCrypt volume,a VeraCrypt volume and a LUKS volume
is in how their crypto properties are stored on the header and dm-crypt is not
aware of any of these projects.

Once you know crypto properties of a volume,you can skip all these projects
and go straight to dm-crypt and manually create the encryption mapper using
dmsetup. All the necessary information about an open encryption mapper looks
like below:

    
    
      [root@ink mtz]# dmsetup --showkeys table
    
      zuluCrypt-500-NAAN-luks.img-2363596225: 0 16384 crypt aes-xts-plain64 afaeef82a6a823e226b0f22289404f1eac5b262b5d1984b7de9328cb571dd3f3 0 7:0 4096 1 allow_discards
    
      [root@ink mtz]#

------
jobigoud
How does fixing such vulnerabilities work in practice? Is he going to patch
the code in private branches so that nobody can infer the vulnerability from
the commit, or will people be expected to update to the latest commit if he
pushes to the public repo?

------
testtesttest
Nowadays facts don't matter. Everybody follows whatever they already believe,
including myself.

If we look at the TrueCrypt audit report:
[https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_O...](https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf)

It says they found 2 high severity issues, 1 low severity issue, 1 undermined
severity issue. All in the cryptography category.

There were additional issues found by the Project Zero:
[http://googleprojectzero.blogspot.de/2015/10/windows-
drivers...](http://googleprojectzero.blogspot.de/2015/10/windows-drivers-are-
truely-tricky.html)

Even when faced with this clear evidence, people consider TrueCrypt as being
safe.

VeryCrypt is under active development, so the situation is much better since
the issues can be fixed in the future releases. However, people might blindly
follow whatever is reported and consider VeraCrypt bulletproof regardless of
the previous experience with other crypto projects.

~~~
wepple
> Even when faced with this clear evidence, people consider TrueCrypt as being
> safe.

I don't understand. If your definition of 'safe' requires that no
vulnerabilities can ever be discovered in a product, you're going to have to
give up and never use a computer again.

Having some high-end crypto experts and some of the best bug hunters audit
your product and then fix the discovered vulnerabilities puts you at the
higher end of the security spectrum.

> VeryCrypt is under active development, so the situation is much better since
> the issues can be fixed in the future releases.

Counter-point for consideration: any non-maintenance code changes may
introduce new issues that weren't part of this audit.

------
baby
Good. Quarkslab is one of the most impressive reverse company I know of.

~~~
thr0w__4w4y
Serious question: what is a reverse company? Flat organization / no hierarchy
or something? Sorry, I just don't know the term.

~~~
baby
I meant "reverse engineering" :D

------
code_research
Oh, they have a Linux versios, too, did not know that. Then it makes sense to
audit this software.

Does anybody have any real life experiences and performance benchmarks for
VeraCrypt on Linux?

Also a feature and performance comparison to LUKS would be very interesting!

Linux Magazin authors, please consider... Thanks!

~~~
mhogomchungu
VeraCrypt on linux uses the linux kernel infrastructure for user data
encryption/decryption and hence its performance will be on par with LUKS
because it uses the same infrastructure also.

Performance of a VeraCrypt volume will degrade only if you use multiple
ciphers.

------
SquareWheel
Is VeraCrypt a legal fork? I thought the license of TrueCrypt didn't allow for
forking.

~~~
whamlastxmas
TrueCrypt said essentially do whatever you want, just don't re-use the
TrueCrypt name. Regardless it's not like they could ever enforce their license
because it would meaning losing their anonymity.

------
whamlastxmas
Can anyone speak as to why Truecrypt/Veracrypt are such difficult projects but
the built-in disk encryption used in Ubuntu/Mint isn't? Seems like everyone
accepts that The Ubuntu/Mint FDE is fine and secure and yet it gets no
attention.

~~~
mhogomchungu
The "built-in disk encryption used in Ubuntu/Mint" is simpler for three
reasons:

1\. All the crypto stuff is done by the kernel and hence they are not
responsible for it.

2\. Most of work that goes into setting up the kernel to manage an encrypted
drive is done by a tool called cryptsetup and they are not responsible for it.

3\. The part where they are responsible for lives entirely in the root's space
and hence they are not susceptible to security issues that arises when trying
to cross a privileged user/unprivileged user boundary.

The reason why TrueCrypt/VeraCrypt in windows specifically have so much
problems is because they are doing everything themselves.

They have less problems in linux because they delegate user data
encryption/decryption to the kernel and they cross normal user privileges to
root's privileges using sudo.

~~~
whamlastxmas
I appreciate the response. I am not sure I understand the parts about "root's
space" and crossing between privileges, it seems like this isn't relevant with
FDE?

------
vasili111
Also read:
[https://news.ycombinator.com/item?id=12289246](https://news.ycombinator.com/item?id=12289246)

