
Ask HN: TrueCrypt audit status? - mukmuk
After raising over $70,000 from the community in October 2013, progress on the TrueCrypt audit has been fitful at best. The last update on http:&#x2F;&#x2F;istruecryptauditedyet.com was April 14, 2014.<p>Two key contributors, Matthew Green (https:&#x2F;&#x2F;twitter.com&#x2F;matthew_d_green) and Kenn White (https:&#x2F;&#x2F;twitter.com&#x2F;kennwhite) remain active on Twitter.<p>I am aware of VeraCrypt and CipherShed but these appear orthogonal to the original audit.<p>Does anyone know what the heck is going on?
======
tptacek
It's in a weird logistical state. I'll take a healthy chunk of the blame.

The TC audit project commissioned iSEC to do a formal code audit. That audit
was completed professionally and efficiently. No smoking gun problems were
found (several nits were, but nothing that would make it any easier to decide
whether to trust the package).

That iSEC audit was the headline achievement for the project, so the fact that
it was finished should reassure people worrying about whether the project did
anything.

After the code audit, the project was supposed to move on to review the
cryptography in TC. Which is where I come in.

Because the project was considering commissioning services from professional
appsec firms, I recused myself from the project (at the time, I worked for a
very large appsec firm). My feeling is that a better use of the TC project
resources would be to set up some kind of crowdsourced audit slash bug bounty.
When the code audit was completed, and after I had left Matasano, I
volunteered to coordinate a crowdsourced crypto audit.

Unfortunately, I was also in the midst of starting a new company and
recruiting cofounders and then the holidays hit and long story short things
went off the rails.

There are two big paths forward for the TC project that I am aware of:

1\. They can rekindle the crowdsourced crypto audit (I'd be happy to remain
involved, or to talk to any other subject matter expert that wanted to do that
job --- n.b., I was going to do the work _gratis_ ). If any kind of formal
review of TC's cryptography is to be done, this is the way to do it; the
project can't afford what it costs to retain professional cryptography
engineers to review the code (real crypto security consulting costs a multiple
of what appsec consulting does).

2\. They can devote all the remaining funds to a public bug bounty for
Truecrypt.

There may be options 3 or 4 that I'm not aware of. I have a decent
relationship with Kenn and Matthew, but I have not been trying to keep myself
in the loop on the project.

There you go: more than you wanted to know about the TC audit project!

None of it has much of anything to do with that weird announcement from last
year.

~~~
matthewdgreen
Thanks Thomas.

This is Matt Green, one of the two people running the audit. As tptacek
explained, we went down a few blind alleys following the public collapse of
the Truecrypt (development) project.

In the last few weeks we've signed a contract to begin a commercial evaluation
of the cryptography in Truecrypt. We've also been doing some internal
evaluation of portions of the source code. For reasons related to getting the
best price, the start date of the audit was allowed to drift forward a bit.
This was necessary to make sure that the donated money stretches as far as
possible.

Rather than giving all the details in an HN post, I'm going to write an update
on my blog (blog.cryptographyengineering.com) but it won't be up until we've
notified everyone involved that we're making the details public, probably
around 4:30-5pm ET today.

~~~
matthewdgreen
Here's the update:

[http://blog.cryptographyengineering.com/2015/02/another-
upda...](http://blog.cryptographyengineering.com/2015/02/another-update-on-
truecrypt-audit.html)

------
Tangokat
The EFF seems to recommend using DiskCryptor for Windows [1]. What are HN's
opinions on this?

Also what does HN think about still using TrueCrypt? Any reason not to?

[1][https://ssd.eff.org/en/module/how-encrypt-your-windows-
devic...](https://ssd.eff.org/en/module/how-encrypt-your-windows-device)

~~~
luxpir
Been mulling this over myself. Doubt anyone with a reputation would like to
stake theirs to another 'solution' that may well turn out to be flawed. Plus
the FDE approach seems broken in that machines have to be powered down etc.

I take the view that for my own threat model (i.e. someone nabbing my machine)
DC, even TC would be perfectly adequate for that first layer of protection.
Advice given by tptacek on using PGP individually for sensitive information
(if I have understood correctly) could then be coupled to that FDE where
required.

For my own purposes this would protect what needs protecting in terms of at-
rest data. A vast improvement over the no-encryption situation.

SSDs with hardware encryption seem to be the new frontline defense for
mainstream users such as myself. Same issues as with any FDE, I suppose, but
coupled with filesystem PGP encryption ought to again offer adequate
protection from opportunistic thieves.

------
wyager
So we all know Truecrypt is dead. What should we use instead?

I don't know of any other software that provides cross-platform, encrypted,
and mountable disk images. We have Bitlocker, Filevault, and Luks, but none of
these work (easily, at least) on different platforms.

~~~
tptacek
The idea that you'd want _cross-platform_ full disk encryption suggests you
may be investing too much faith in the powers of full disk encryption. FDE
does basically one thing for you: it reassures you if your laptop is stolen
from the back seat of your car or left in a cab.

Cross platform _encryption_ is very important, and you should look for good
solutions (most of us who rely on encryption for real operational reasons just
hold our noses are use PGP). But full disk encryption has very limited
utility. The idea of a USB drive you can plug into any computer that is locked
by default is attractive, but you can get better security out of a USB drive
that holds nothing but files encrypted at the application layer.

More:

[http://sockpuppet.org/blog/2014/04/30/you-dont-want-
xts/](http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/)

~~~
Perseids
> You can’t authenticate the data. Authenticating every sector is too
> expensive. Try to (painfully) authenticate the whole disk and any disk error
> trashes the disk. Maybe your users enjoy exciting games of chance?
> Authenticate arbitrary groups of sectors and you can play Russian Roulette
> with your files. ([http://sockpuppet.org/blog/2014/04/30/you-dont-want-
> xts/](http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/))

Out of interest: Doesn't the use of error detecting filesystems like ZFS and
Btrfs solve the authentication problem? I don't have anything resembling a
formal argument, but intuitively having each block checked in a Merkle tree
like fashion should inhibit attacks where attackers can only change blocks in
a random manner or restore old backups of the blocks. Of course time traveling
- i.e. replaying - the file system as whole is still possible, but selectively
manipulating the data should not.

~~~
alcari
The ZFS crypto implementation (which isn't really available outside Oracle's
Solaris) uses AES-GCM, which solves the authentication problem.

~~~
tptacek
If you have filesystem encryption, block-level encryption is probably
unnecessary. Filesystem encryption is in most ways superior to block-level
crypto.

~~~
YAYERKA
The comparisons between filesystem-level vs. block-level encryption that I've
encountered usually make a common distinction; namely that file metadata is
still present when only applying fs-level encryption. What are some attributes
of fs-level encryption that would make it a superior choice over block-level?

~~~
tptacek
There are three huge advantages filesystems have over block devices when it
comes to encryption:

1\. They have storage flexibility, so they can allocate metadata to
authenticators and nonces. The fact that sector-level crypto can't do this
means that the "state of the art" in efficient sector crypto is essentially
unauthenticated ECB mode.

2\. They're message-aware, so they can apply authentication at meaningful
boundaries; a block crypto device is essentially a simulated hard disk, and so
it doesn't know where files begin and end.

3\. Being message-aware, they can protect files at a better level of
granularity than "all or nothing", which for instance is the security failure
that made it so easy for the FBI to convict Ross Ulbricht for Silk Road.

A lot of concerns about filesystem crypto stem from the fact that filesystem
crypto precedes sector-level crypto, and most of it was designed (or has
designs tracing to) the 1990s. What people who don't spend a lot of time
studying crypto should remember is that nobody knew how to encrypt _anything_
in the 1990s. It was a unique and weird time, where there was a lot of demand
and interest in crypto, but not enough knowledge to supply crypto effectively.

So we should be careful about judging filesystem crypto by the standards of
the 1990s.

------
lnanek2
Didn't TrueCrypt throw in the towel?

------
stith
As far as I know the audit project was abandoned when the TrueCrypt developer
did his dramatic exit. Cannot remember a source for that though.

~~~
tptacek
No, the project was not "abandoned" like that. What source told you that?

~~~
stith
Apparently none! Apparently that idea made it into my head somehow, I must've
just jumped to conclusions and assumed I read it somewhere. Oops!

