TrueCrypt must not die | Hacker News Reader

TrueCrypt must not die

truecrypt.ch

207 pointsjoshcrews98 comments

Also, it appears someone finally got a hold of a Truecrypt dev. The project was just shut down from lack of interest. No drama about auditing or, crazy NSA conspiracies after all: https://twitter.com/stevebarnhart/status/472203503478509568

Edit: That tweet was deleted for some reason, but the rest of the thread is still there: https://twitter.com/stevebarnhart/status/472192457145597952

Yeah, this comment appears to be spot on as well:

http://krebsonsecurity.com/2014/05/true-goodbye-using-truecr...

The funniest part about that comment is the response that says "I really was leaning toward NSL, till I read this post."

Head-desk-head-desk.

For me this tweet is 404, what is its content?

Sorry, I didn't really want people trying to further bug the supposed dev. Steve Gibson has a good enough roundup. I wish he didn't use my info though :)

You'll be alright.

He'd tell you, but he's been NSL'd.

tweet was deleted for some reason. Here's another from the thread: https://twitter.com/stevebarnhart/status/472192457145597952

It looks like it was deleted because they were concerned about accidentally outing the developer. Which seems like a legitimate thing to be concerned about.

I'm shocked, shocked: https://news.ycombinator.com/item?id=7812476

topsy still has the tweets cached:

http://topsy.com/trackback?url=http%3A%2F%2Ftwitter.com%2Fst...

and for the user:

http://topsy.com/s?q=from%3Astevebarnhart&window=w&type=twee...

No it doesn't.

At least from here it looks like they took the posts down as well.

I have much doubt about that since BitLocker is certainly not good enough:

https://twitter.com/stevebarnhart/status/472195239005147136

And why not just writing that you no longer feel motivated to continue the further development of your software? It is very common after all …

The developer(s?) who made TrueCrypt did it for their own reasons.

They didn't necessarily do it because they wanted to "stop teh NSA." A lot of people who wanted to "stop teh NSA" started using TrueCrypt, and so they assumed that their goals lined up with TrueCrypt's. But maybe they didn't.

Maybe the developer using TrueCrypt was perfectly happy with "defend against anyone short of the NSA, especially since the NSA would need to expose their ability to break into this in order to do anything bad to me." There are millions of people who legitimately share that threat model.

We can parse out each comment in the source code like lawyers fighting about a comma before SCOTUS or biblical scholars debating on the definition of a word in Hebrew. We will never know. But there is a really big possibility that the developer(s) consider BitLocker acceptable, even if it's closed-source by Microsoft.

EDIT replaced an instance of "BitLocker" with "TrueCrypt" in second paragraph, whooops!

Exactly, and it's amazing what a sudden lack of motivation (for a FREE project after 10 years) will do to someone compared to how you feel when you first are building and all giddy and have high aspirations. They're probably worn out and tired and so suddenly they don't feel as strict need to adhere to their previous guidelines.

However, I personally find that interesting since I'd think in today's climate it's even more important and they were getting lots of exposure.

At what point did you answer that simple question of - well why didn't they just say they are not motivated to continue the project any longer, but instead say Truecrypt is not secure.

I'm not sure you can apply Occam's Razor here. You will only break your blades as you search for a simple answer.

Maybe he was pissed.

Maybe he really didn't want to support it any more, and would feel really bad if people's stuff got compromised on his watch, so he wanted everyone to stop using his stuff as hard as possible.

It doesn't mean anything. That's the exact same reply someone under a gag order would give too.

Bob: [practising] As you know, sir, we have several loans with your institutions, all "past due". But what does "past due" even mean, you know?

Gene: It's brilliant! There's no such thing as time!

@stevebarnhart: ask him if he would continue for $70000...

Hope they can give a gpg signed mail content.

It would be nice if the people who pick up and run with the "reboot" of Truecrypt's project management had a background in cryptography. Do these people?

Did you not see the .ch domain name ?

You can rest assured.

Also what is it with the people who suddenly seem to believe Switzerland is a cypherpunk haven? It _really_ isn't.

It's clearly a ploy to get everyone backdoored. Just look at Crypto AG.

Hm. Is that Websters definition of "clearly", meaning "easy to perceive, understand, or interpret", or HN's definition, as in "it's clear someone or some agency got to the developers and they just pulled the ejection seat for their own legal protection"?

I was hoping the italics spoke for themselves, but I'd better clarify it's the latter. It seems to be an Internet-wide phenomenon to jump to the most bombastic possible conclusion given a limited set of facts.

Sorry, I was just trying to use you to riff.

The domain is registered to Joseph Doekbrijder [1] who does seem to be working in the area. You might be much more knowledgeable about were to look for his crypto background than I am.

[1] http://www.linkedin.com/pub/joseph-doekbrijder/2b/384/43a

I don't believe the TrueCrypt license allows this kind of redistribution, does it?

Then again, with anonymous developers and unknown jurisdiction, it may be moot.

From a practical view the original authors were anonymous, would they really shed that to sue somebody forking their code against the license? Probably not.

Looking at the license simplifications part of TrueCrypt 7.2 [1], it may be allowed.

[1] https://github.com/warewolf/truecrypt/compare/master...7.2#d...

Upon skimming, it looks like it still retains some clauses like: "The name of Your Product (or of Your modified version of This Product) must not contain the name TrueCrypt [...] nor any other names confusingly similar to the name TrueCrypt" and "All graphics contained in This Product (logos, icons, etc.) must be removed from Your Product (or from Your modified version of This Product) and from any associated materials."

...but that actually doesn't seem all that insurmountable. Hm...

TrueCrypt 7.1a - the one with the actual functionality - wasn't released under this license. It was released under the earlier one. And I don't think it allows for this version or later ala GPL. I'm not sure of this, though.

Well could you not simply take 7.2 and patch it back to something resembling 7.1a, thus keeping both the license and the functionality?

Only if you write those patches without referring to the 7.1a source, which would be difficult since thousands of lines have been removed.

It says derived programs shouldn't be called "TrueCrypt" and shouldn't be ascribed to the original publishers, which honestly seem like pretty mild requirements.

https://github.com/warewolf/truecrypt/blob/33c0b8457051796fa...

The big issue was the clause that didn't protect those who forked from copyright infringement or being sued and the devs said that was intentional. Although, i doubt they'd really want to come out and make themselves public to pursue that.

So they are right off on the wrong foot, with that domain name.

I belive any TrueCrypt fork should require contributions to be dual licensed under TrueCrypt's original license and BSD. In time, the project can shed original files and re-implement them under BSD or any other GPL compatible license.

So far there isn't any derived code. The truecrypt.ch domain seems a reasonable place for people to regroup. If/when a new release comes out, the community can think about a new name and register a new domain.

The Truecrypt licenses also say that it cannot be sold, which makes it non-free and non open source. The OSI even said, "it is not at all appropriate for [TrueCrypt] to describe itself as 'open source.'"

http://www.infoworld.com/d/open-source-software/truecrypt-or...

They are redistributing the original unmodified source, so it shouldn't go against the 'derivation' requirement..

My opinion, the fact that some security researcher was going to be getting more money than the actual developer ever made off the project must have been infuriating. I think that's good enough reason to burn the project to the ground.

or not start it at all

The license issues surrounding TC are reason enough to not restart the project.

The signatures and binaries are not served over HTTPS. It would be prudent to compare them to other sources.

Just for reference, SHA1s posted from an independent source yesterday: https://news.ycombinator.com/item?id=7816109

Actually it would be good if the webmaster behind this reboot got SSL set up. Especially if this is going to be the new most authoritative download source.

SSL is better than no SSL, but for better assurance they should offline sign the downloads.

That would be prudent regardless. If you trust HTTPS, why verify the PGP signatures? And if you don't, verifying the PGP signatures does not get you anything if you have no reason to trust the key.

This looks like a bootstrap site that was thrown together in an hour by two guys with twitter accounts and $10 for a domain name. I really doubt they're going to be doing any dev work.

Why does the amount of effort on the site matter? I don't understand how that tells you anything about the project or its likely outcome.

well the fact that they are asking for a copy of the original site isn't a good start.

The original dev's made it clear they don't want people to continue with the TrueCrypt name. If they were really interested in continuing the project for the sake of security they would have chosen a different name.

Original site archived here > http://archive.today/www.truecrypt.org

Would you trust it more if they used Comic Sans instead of bootstrap?

Still have no idea what's the "unfixed security issues", and few guys mention about it. I image there the "security issues" will be (if it exist): 1. because key are easy to stolen by coolboot or trojan. 2. because it has backdoor, will save key to a hidden place. 3. because it will leave some information in other place, like 2 but it's implantation problem. 4. because it use a vulnerable algorithm to generate key. 5. because pbkdf2 or aes256 is broken but nobody known it. exclude 2 and 3, change to other software it's not help at all, algorithm almost same.

If we believe the person I was in contact with (big IF, I know), there are no current issues, but it is by definition "harmful" to continue use because it is no longer being maintained. In fact, the person requested I tell Steve Gibson to not distribute or include a notice telling people not to use it.

if the developers of Truecrypt are anonymous and the license doesn't allow something like this, would this allow us to find out who the developers are if they sue?

To what end? Just because one can steal someones code or force them to reveal their identity doesn't mean it's a good or nice idea.

Apologies if I missed anything, I don't follow this truecrypt stuff too closely.

If they sued, yes, they would have to reveal themselves. One of the developers got dox'd recently, which may have something to do with shutting the project down. (https://translate.google.com/translate?sl=ru&tl=en&js=y&prev...)

Honestly, I was hoping this drama would result in the implementation of hidden containers for other crypto solutions (dm-crypt, etc).

Hopefully that may still happen.

The FAQ for cryptsetup states: https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQue...

This means that if you have a large set of random-looking data, they can already lock you up. Hidden containers (encryption hidden within encryption), as possible with Truecrypt, do not help either. They will just assume the hidden container is there and unless you hand over the key, you will stay locked up. Don't have a hidden container? Though luck. Anybody could claim that.

Hidden containers perhaps won't be enough to protect you from being locked up, but that is not always their purpose. One purpose of hidden containers is to make the presence of information hidden from the attacker. They may lock you up, but they will never really know if you had encrypted information or not. That means you win something.

I think that's a very narrow view.

It assumes there are only two possibilities, either you live in a "free country" where you can refuse to hand over the key, or you live in a totalitarian state where the police will decide to beat you if they suspect you have crypto software, and will keep doing so no matter what you say.

There is a lot of middle ground there. For example in the UK, I believe you are legally required to provide the decryption password. But I don't think the police there would be likely to beat you if they think you may have a hidden container. They could argue that they believe you do, and you would respond with "prove it!", and I doubt it would go any further (unless they had some evidence that you specifically were using hidden containers).

There is value in hidden containers in some circumstances. It's disappointing to see the cryptsetup maintainers take this position.

This is a bad idea. TrueCrypt should be put to bed for good. An event of this magnitude is easy justification for dropping TrueCrypt. It serves an extremely delicate purpose and this raises far too many red flags to ignore.

Place your energy in the alternatives. I wish you could downvote things on HN, if only because this is downright dangerous and needs to be read by as few people as possible.

There is a $30,000 audit currently underway. There will be no security problems un-turned when they are through. That's assuming there are any to begin with (Personally, I think not).

I see no issue picking up the codebase and running with it.

Of all the subsets of the software development world, crypto is the one to be taken most seriously. TrueCrypt was always developed in the shadows, and the recent controversy takes the nails they've set and hammers them firmly into the coffin.

Audits aren't perfect.

It's code. There are no secrets.

Problems come up when nobody reads the code. Right now, there's an awful lot of people reading this code (Given the strange warning's posted on the TC site).

That's a fine attitude for normal code, but crypto is a whole different ball game. Linux security was significantly reduced at one point because somebody changed int i to int i=0, something most developers would thing is a positive. Side channel attacks are extremely easy to create and extremely hard to find. And, unfortunately, the "many eyes" thing doesn't work here because it requires experienced, knowledgable eyes, and there aren't enough of those, and they are usually busy getting paid, researching how to break software or building their own stuff.

> Linux security was significantly reduced at one point because somebody changed int i to int i=0

Could you please elaborate on this one?

Seems to me they relied on the uninitialized memory of a stack variable as a partial source of randomness for key generation.

Initializing the variable with 0 removed that part.

Your explanation makes sense. Though I'm still curious as to when this happened and what the impact was.

It's been a while. I should have restricted it to Debian: http://jblevins.org/log/ssh-vulnkey

[fridge brilliance] Maybe, after the OpenSSL debacle, they realised that the only way to make a truly secure product was to get a lot of eyeballs on the code, hence the dramatic diva flounce to grab attention... [/fridge brilliance]

> There will be no security problems un-turned when they are through.

I really really doubt this is a claim the folks doing the audit would make.

> That's assuming there are any to begin with (Personally, I think not)

They already found a few flaws. Nothing major though: https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_A...

If you can make that happen with $30k, you can get very rich!

Would you mind pointing me in the direction of a good alternative? Thanks.

The Arch Linux wiki page has an excellent overview: https://wiki.archlinux.org/index.php/Encryption

Hmm, it doesn't appear that any of the options there work on Linux, OS X, and Windows?

You are correct. These options are not very portable. My point here is not that the alternatives are ready for non-technical users, but that developers should focus on realizing that future instead of maintaining and advocating a fork of dangerous software.

Edit: I was wrong, dm-crypt is supposedly accessible on Windows and maybe accessible on OS X. Non-FDE methods have decent spread. https://wiki.archlinux.org/index.php/Encryption#compatibilit...

> instead of maintaining and advocating a fork of dangerous software.

This smells of hyperbole. Why do you consider TC to be _dangerous_ software? Lack of maintenance? Speculative possibilities regarding recent events?

If the rumors are true that the TrueCrypt devs are throwing in the towel, that discounts a couple of dangerous scenarios I can think of leaving only lax maintenance.

Maybe the sudden, big, red "WARNING: Using TrueCrypt is not secure" from someone who is in the best position to know and who has been trusted for 10 years to make decisions about what is and is not secure?

Without anything else to go on, it seems the most responsible assumption (for now) is that the software is in some way dangerous.

I think no. Given what we know, the most reasonable assumption is that the developers did not want to abandon the project to the wind and the future without leaving a proper landing page indicating that the project is unmaintained. Vulnerabilities could be discovered in the future.

This is true of every piece of software, always. No specific flaws have been mentioned by anyone. Here, the (supposed) developers flat-out told us they just lost interest. There hasn't been a release in years, and now -- if his identity were to become known -- a negative result on the audit (no vulnerabilities found) would not be interpreted as an endorsement from him that the software is secure.

When/if the vulnerability is found, he will not be required to say "I told you so" or "I'm sorry." The last ten years absence of evidence is not evidence of absence, that's just common sense.

And there is one vulnerability I think I've heard that's not surprising anyone -- TC keeps the keys in memory while the partition is mounted. Anyone with enough practice can supposedly freeze the chips, unplug them, put them into another machine, and boom grab your keys without disturbing the frozen bits. Presumably law enforcement and other APT entities will be getting better at this technique over time.

If you're worried about this and other threats, best to keep your partitions unmounted.

I disagree. TrueCrypt (for better or for worse) made encryption available to the masses in an easy to use application. Without it, similar level of encryption requires knowledge of unix command line or expensive commercial products. The events that have unfolded do certainly raise the stakes for the TrueCrypt audit, but at present, I am still better off using TrueCrypt, than nothing at all.

I'm speaking to developers who would work on something like maintaining a TrueCrypt fork. Instead, improve the usability of the alternatives to solve the problems you've raised.

Who says they aren't going to fork and continue development?

It's just a landing page that a couple of guys put up while they try to figure out what direction to take. Since there's an audit going on right now, when it's done they'll probably start fixing the problems and releasing new versions. Have a bit of patience.

Having taught hundreds of people how to use True crypt over the years, I would certainly say that it was hardly easy for the average person to use.

It was, however, easy enough to use for anybody capable of administering their own Windows PC, a situation which most of us on this site have been in at some point in our lives.

Hmm, I think the YC News people are not the average users :)

The problem really came in Africa and the Middle East were overall IT literacy is low. People could often use a computer but were not familiar enough with it/scared to break something that they were afraid to really problem solve - esp human rights defenders in their late 40/50s in these places.

So for example, if taught A then B = C, TC was fine. The problem often came when A then B = Z, then TC became a problem. It's UI/UX and use of language (why call something "Mount"? Just use the word "Decrypt" for gods sake! - yes its not perfectly accurate but its easier for people to understand.) was pretty intimidating for many of the people who's lives really depend on it.

I would love to see it live on with no new unneeded features, no changes made unless they are to fix bugs. Keep a stable long-term product and get as many people as possible looking over that code for flaws.

Anonymous development on a security relevant Project is no longer an option.

Why not?

Because trust is an important commodity on a project like this. Higher trust means fewer horrible things slipping past the review process.

Anonymity is out and I'd say that being an "independent" crypto person that has to defend themself will not get you very far once you have come to the attention of the wrong people.

So what options remain for the person that starts the "next Truecrypt"? The only true safe haven I can think of is employment at a public university. In many countries here in Europe the security researchers working at universities can operate under what is called "academic freedom".

I wonder how that will be destroyed.

Trust is indeed important, but is connecting a name (or a number of names) to a project the only way to establish trust?

Why don't you send TrueCrypt.org a few dollars then?

The developers have already decided to call it quits. More money probably won't help.

Reply on news.ycombinator.com