Live data from Hacker News

TrueCrypt must not die

truecrypt.ch

71–80 of 103 posts

Re: TrueCrypt must not die

#71
post #33

Earlier quoted context omitted.

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).

[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]

Re: TrueCrypt must not die

#72
post #10

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

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

Re: TrueCrypt must not die

#73

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

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.

Re: TrueCrypt must not die

#75

Earlier quoted context omitted.

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...

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.

Re: TrueCrypt must not die

#77
post #54
post #10

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

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!

Re: TrueCrypt must not die

#78

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

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.

[deleted]

Re: TrueCrypt must not die

#79
post #76

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.

Re: TrueCrypt must not die

#80

Earlier quoted context omitted.

> 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.

Post reply on HN