Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TrueCrypt must not die

truecrypt.ch

Post reply on HN
Print view View original

61–70 of 103 posts

Re: TrueCrypt must not die

#61

Post by shawnz »

WatchDog wrote: post #56
JohnTHaller wrote: post #9

Earlier quoted context omitted.

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.

Re: TrueCrypt must not die

#62

Post by neurobro »

Zancarius wrote: post #45
Sir_Cmpwn wrote: post #42

Earlier quoted context omitted.

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…

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

Re: TrueCrypt must not die

#63

Post by thejdude »

nikcub wrote: post #48
buddylw wrote: 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

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.

Re: TrueCrypt must not die

#64

Post by zurn »

dendory wrote: post #58
voltagex_ wrote: post #2

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

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.

Re: TrueCrypt must not die

#65

Post by zurn »

Alupis wrote: post #27
Sir_Cmpwn wrote: post #24

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.

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

Re: TrueCrypt must not die

#66

Post by secfirstmd »

Afforess wrote: post #30
Sir_Cmpwn wrote: post #24

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.

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.

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.

Re: TrueCrypt must not die

#67

Post by quasque »

SoftwareMaven wrote: post #55
Alupis wrote: post #33

Earlier quoted context omitted.

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 ey…

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

Could you please elaborate on this one?

Re: TrueCrypt must not die

#68

Post by eps »

buddylw wrote: 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

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

Re: TrueCrypt must not die

#69

Post by nikbackm »

quasque wrote: post #67
SoftwareMaven wrote: post #55

Earlier quoted context omitted.

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 ey…

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

Re: TrueCrypt must not die

#70

Post by cornholio »

Lagged2Death wrote: post #11
callahad wrote: post #4

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.

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.

Post reply on HN