In 2006 or 2007 I was running a non-trivially sized project for a government agency, and we wanted to use TrueCrypt on every new machine we were rolling out.

The default licensing arrangement certainly meant we were (legally) covered, but we sought out the author and offered a financial arrangement in terms of support (we weren't proposing an especially onerous arrangement, and were quite clear in our 'improvements we fund, we're happy to go back to GPL' and it was very much an early stage of negotiations from our perspective). Weirdly it was dismissed outright.

Highly anecdotal, and the guy I had that contacted the TrueCrypt author may have given the wrong impression (unlikely), but since then I've always felt the project was in the 'slightly odd' category.

Or maybe he just figured that taking money would mean that people would make assumptions about services rendered for that payment.

Sometimes it is better to not be associated with certain sources of funding if you want to keep your reputation clean and not being the subject of 'sold out' claims even if that isn't the case.

Sure, and while I can't recall the precise details of the correspondence, we were certainly very sensitive to that.

I'm a long-term free software advocate, and the network admin that was talking to the TrueCrypt author(s) was similarly minded, so there was absolutely no question we were seeking to taint the licence, risk the independence, demand credit or attribution, or anything along those lines.

Part of advocating free software in government agencies then (and probably also now) is that you are obliged to CYA in terms of having some mechanism by which you can demonstrate you can obtain support in the unlikely event of problems. It's a real pain in some cases (such as this), but in practice it's usually lip service at worst.

We were under no illusions - we'd heavily tested the software, and knew it was fit for purpose (it was a Windows XP rollout, so pretty well trodden ground). We were confident we'd never have to contact them again, once we'd thrown them some cash.

I would suggest that going to work for "the/this government", even on a contract basis, may and probably has all sorts of implications including perhaps a majority of which and the most concerning are not actually spelled out in the direct contract, itself.

Just trying to evaluate what those might include could be a very extensive and unachievable exercise.

I can imagine someone in a position like that of the TrueCrypt developers being loathe to enter into a scenario bringing with it such ramifications. Even setting aside any personal ideology, it has the appearance of a swamp in need of the obligatory sign, "Here Be Dragons".

Just my blue sky speculation, but based upon a number of years of casual and outside observation of facts and anecdotes that make it into the sphere of public knowledge.

I can understand the sentiment you describe.

But there was no 'come work for us' implied or explicit, of that I'm sure.

This was small to medium-sized Australian government agency, knowingly talking to people we (assume) were based in either Europe or the USA, either way off-shore.

We didn't even have a tentative contract to hand, and as I say I can't remember the details, but I suspect our opening inquiry was along the lines of 'has anyone else talked to you about this type of deal', leading into a 'we'd just like something on paper that will satisfy management that we've done due diligence'. Our expectation was that it would effectively be a donation to the project.

Clearly there was, for us, back then, no perceived risk at all TrueCrypt was about to be abandoned - and the project's response to fixing bugs far exceeded any non-free / proprietary software we were concurrently deploying.

Thanks for the clarification. Although I still think a person in a position such as that of the TrueCrypt developers might be reluctant to take anything from a government or provide them any sort of... statement.

May I ask how much cash--more or less--you were prepared to throw at him?

Also, did they guy who contacted the TrueCrypt author mention any dollar amounts?

I've noted a few people assuming the male pronoun. It may have been an intentional misdirection at the time, but I do recall my guy had expressed mild amazement that the developer he'd been talking to was a female.

That aside ... :)

We hadn't talked cash at all, it hadn't even gotten that far.

I would speculate, thinking back at it, that I'd have been happy to throw somewhere around $10k at them. I'd just managed to save about $150k on MS licences, so my budget was looking healthy, and TrueCrypt solved a goodly number of our regulatory problems.

As I mentioned above we were in the very early stages, and were likely couching the arrangement in terms of a donation (in return for some vague assurances of assistance if it all went titsup).

So fork it anyway and call it something else. According to the license[1], this is permitted.

1. https://www.ohloh.net/licenses/TrueCrypt_Collective_License (see section III)

Yes, the title should not say "TrueCrypt developer says no to license change for forking" but "TrueCrypt developer says no to license change for forking with the same name and removing copyleft"

It's unclear to me if the licensing terms of TrueCrypt allow others to fork it even without the developer's permission, perhaps without the TrueCrypt name?

Resources were invested by some to audit the code. The developer is uninterested in letting the code go on. I think the lesson is, don't invest significant resources in supporting a shared codebase, unless it's got a license that will let people continue to use/develop the codebase even without the original developer/owner's permission.

No, they don't. You're allowed to inspect the source code for any reason, but the license does not allow redistribution or modification. TrueCrypt is not open source or free software.

I don't remember hearing that redistribution wasn't allowed, I'll admit I haven't read the license carefully, but what I understood was the original license forbade modifications through the advertising clause (making it incompatible with open-source licenses):

If you take and modify the source, you must remove all references to the "TrueCrypt" name inside of the source code and program interface and not call it TrueCrypt. If you redistribute it unmodified, you must leave the "TrueCrypt" name intact. I don't have a source for the second term, but it would seem to be impossible to have an unmodified work that didn't call itself TrueCrypt -- by removing TrueCrypt branding, you fulfilled the terms of the first part, even if the functionality of the software was actually unchanged.

So the license is non-free because it duplicates trademark law within itself? It's annoying how things with no real impact can ruin compatibility.

This is a funny thing about FOSS licenses, and I guess a commonly known thing about the advertising clause as it relates to FOSS licensing. The wording in the GPL that causes this situation I believe is: "No additional restrictions may be placed on the redistribution of either the original work or a derivative work."

The intent of the advertising clause is to assert and maintain control over the software in the hands of the creator/owner; this is fundamentally incompatible with FOSS ideology, where anyone can fork and edit, and the leadership of the project is "de-facto" as in the eyes of a community rather than "de-jure". That being said, it is annoying.

If the author is not willing to unmask him or herself, I'm not convinced courts would allow an author to maintain anonymity while suing you for copyright violation. Particularly given the specifics of this case: the copyrighted work being freely available, and the author publicly stating that it's abandoned.

You can certainly keep on using it, and the license probably allows you to modify it on our own for internal existing projects. So it will be around for a little while.

But why try to keep the dead horse alive? TC is really weirdly written, as a GUI app that has a command-line stapled onto it, instead of the other way around. (Last time I built it for a headless machine, I still needed wxWidgets.) Especially with the specter, even unlikely, that some unknown person may possibly rise up to claim ownership of the project someday.

We should understand TC because we're using it, but we should think about the next thing.

If you have the right to copyright under a pen name, should you not also have the right to sue without revealing your identity? A right that can't be exercised doesn't exist.

Rights can come in conflict with one another, and when this happens one has to yield. The public has the right to open court records, and defendants have the right to know who's suing them. These rights usually outweigh any right the plaintiff may have in suing anonymously. It is possible to sue anonymously in the U.S. (e.g. "Jane Roe" of Roe v. Wade was a pseudonym) but IANAL so I don't know by what standard this is determined or whether the TrueCrypt dev(s) would qualify.

It doesn't matter. A licensing pall cast over the project severely hamstrings the future maintainers of the project; big companies, for instance, will be reluctant to get involved while there's a cloud over it.

The TrueCrypt developer(s) may be under a government gag order and this may just be their way of letting us know without saying "The Government can crack TrueCrypt, it is not fit for purpose anymore"

This may be another Lavabit situation.

Apart from one Tor developer who, without presenting any details, claims there was a "warrant canary" from Truecrypt almost 10 years ago, can you cite a single crypto expert who believes that this is the case? Or are you just saying about Truecrypt what you could say about virtually any other privacy-relevant software on the Internet at any time?

But there's a secret message in Latin. How much more proof could you ask for?

If that's the case (and it doesn't seem that unlikely to me), I think a thank you is in order.

Thanks buddy!

It sounds like the developers found a critical flaw, and gave up. I'm not saying its purposely malicious government inserted, or just plan negligence.

But from this response and how their website changed really makes me inclined to believe something is fundamentally broken in truecrypt.

Can I ask whether you have a background in encryption or in disk software sufficient to make such a determination authoritatively? Because I know several people that do have that background and none of them have come to this conclusion. It would be interesting to know why your interpretation should be taken more seriously than theirs.

I put it this way --- bluntly, aggressively --- because there's a drive-by element to your comment; "critical flaw", "fundamentally broken", but absolutely no details whatsoever.

"There is something fishy" is true because projects don't normally shut down so suddenly. But a lot of TC has always been usual, from its license to the hidden identity of its developer[1].

For whatever reason, he[1]'s done with the project. Maybe the wife and kids are more interesting these days. Maybe he got offended at auditors being paid and not him. Maybe he feels a responsibility towards his users and since he cannot actively defend them he wants them to move inside someone else's castle. Maybe he died and his brother took over the account long enough to say "we're done" and his brother really doesn't want to talk about it no matter how weird you think it is that his brother doesn't want a bunch of people on the Internet on his lawn like they were on Satoshi's.

It's like a bunch of blind cryptographers trying to describe an elephant.

[1] Assuming a heterosexual singular male just for convention.

A person experts involved in the TC audit have reason to believe is involved in the TC project sent an email, which I read, which said (paraphrased) "We started TC to get Windows disk encryption. Windows now has better disk encryption. We're done."

I know that's shocking to OSS developers, but not everyone cares (at all) about Linux.

i hope you know that bitlocker is not available to all windows users[1]. These TrueCrypt developers seem to not be aware of this apparently and hence their reason for stopping development is flawed.

[1] http://en.wikipedia.org/wiki/BitLocker

Why was this down-voted? He is right, bitlocker is available only for some versions. Plus, there is no way to know whether bitlocker is better or worst and there is no way to audit it.

I didn't downvote, but saying the developer doesn't know what he's talking about and that his reasons for deciding to stop working on a project are flawed are each likely to be downvote magnets.

I may refer to this thread the next time someone asks "why don't companies give explanations to candidates they don't hire?" The answer is that the candidates feel compelled to prove that the company's reasons are flawed. Look how they react to someone deciding to stop working on a project.

I think its more likely the author is slightly unstable and has gotten pissed off at the public discussion around it

Or that people continue to bother him/her with bombarding emails, public cynical skepticism, baseless speculation, and more.

How about we stop bothering the poor developer(s) and let them be. They have already contributed more to the world than most of us here - time for them to get the well deserved rest they seek.

I'm happy to leave the dev alone. I don't really care about the dev one way or the other.

What I don't like is to have some piece of infrastructure I've come to depend on yanked out suddenly, being mislead about the reasons, and being left with only onerous alternatives (rewrite the whole thing or stick with 7.1a indefinitely). That these two options are onerous is not speculation or simply some kind of bad attitude. It is a fact.

Whether this action was deliberate or just incredibly clueless and negligent, treating TrueCrypt users this way is crappy, and I think it's OK to say so publicly. I'm grateful for the development of TrueCrypt. But that gratitude doesn't translate to a free pass for all subsequent terrible behavior afterward.

If the dev's identity was known, he/she might take a lot more heat than a few harsh words. Considering the needless trouble he's putting people through, a strongly-worded letter of protest is a pretty mild reaction.

It sounds like you should pay money for software. If no one is willing to sell you a support contract, don't use it.

Well know cryptographers opinion on this topic: https://twitter.com/matthew_d_green/status/47895635223707648...

He tweeted: Most commercial encryption products are junk.

Eh in reality any decision or assumption is no more then us putting ourselves in the developers shoes based on the few communications that have took place.

We likely won't know what happened for several years after, if we ever learn at all.

I just find it hard to believe we can't work out who these people are. Impressive work on their part. bet the NSA do!

they might be nsa guys :) who knows.

Typically using source code as a direct reference would mark the product as a derived work. You need an appropriate free license to do it. I wonder if this written premission is enough to remove the taint.

I used to think that - at least sometimes - redeveloping something from scratch is a good idea but in the last couple of years I realized that this rarely if ever the case. The problem is that you will introduce a lot of new bugs and reintroduce bugs that got fixed long ago. There is no good reason to believe that you can develop a piece of software without making hundreds of the common small mistakes that just happen - off by one, switched sign, missing null checks, you name it. And even if you have to deal with one of the worst code bases you have ever seen, the developers will already have spent countless hours wiping out such problems. Starting from scratch not only means getting rid of bad code, it also means throwing a lot of useful work overboard.

So if I have to deal with The-Worst-Code-Base-Ever™ I create a new project and copy the code into the new project file by file in the order you would develop from scratch and clean it up before moving on to the next file. Improve the naming, split large functions, extract common code, unify similar code, look for and fix bugs, improve algorithms, comment out code that references code not yet in the new project or code not yet used and when there is a good opportunity improve the architecture - given that you already understand the code base well enough. It takes time, you touch some files a hundred times and move around bits and pieces seemingly forever, but I am pretty confident the result is better than rewriting everything from scratch. All this might be not such a good idea without good tool support, but if moving and renaming things or changing function signatures project wide is just a matter of seconds, there is real value in doing it incrementally instead of trying to do and get it right all at once.

Starting with tests is usually a better first step. Mostly functional tests are easiest to write.

If you can find parts to replace into separate services, that is best. So you can slowly migrate the system, whilst gaining the benefits quickly for the new code. That way, if the project takes a year, bug fixes can happen in the new code. Also features can be added to the new code.

Also, if after a year and the old system is still being used, then valid questions may be asked about what use the new system is.

YMWNV

There's an Open Source implementation for Linux at https://github.com/bwalex/tc-play ; perhaps that would serve as a better starting point.

Being forced to start from scratch seems a real shame. TrueCrypt as it is, is a reasonably stable and mature piece of technology. Far better to swap out the broken/substandard bits than start solving a fundamentally hard problem all over again from step one.

There is no guarantee that a rewrite would be better than the original. And it will take man-years worth of effort to get even to where TrueCrypt is right now.

It's not always easier to swap out broken/substandard bits than to start over again with the original as a reference. In the opinion of this particular Truecrypt developer, in this particular case it would not be.

I can only assume that the person who posted this was "Matt" as signed off on the original email, but Matt who? Why should we trust this?

Matthew Green https://twitter.com/matthew_d_green/status/47872127131675852...

LibreCrypt around the corner

I generally don't advocate complete rewrites, but it seems to be the best option in this scenario. Why is everyone so opposed to doing this? I don't mean that rhetorically. I truly don't understand. I don't want to downplay the difficulty of such a project, but I regularly see brilliant developers here at HN and elsewhere scrambling to create something meaningful. Here's an excellent opportunity to build something that would have widespread use, with both cultural and political impact, yet there seems to be a lot of reluctance to actually take on such a project. Instead, we keep speculating about anonymous developers who have made it clear that they're done and want nothing to do with it anymore. We even have permission to use TrueCrypt for reference. Seems like an awesome opportunity for developers smart enough to do it.

I think a lot of developers would break at the point of native cross platform support. I like writing stuff people use, that's cool, but it's a huge pain to write for and test on platforms I'm not going to use like Windows and Linux. I'll do that if you pay me, sure, but not for fun. Maybe not even for the fame of having a more popular fun project.

Cross-platform would likely require Java as a base runtime, something that might not be appetizing for some developers.

With that being said there's many brilliant polyglot developers with lots of experience and maybe it's a task for developers with more years than average under their belt as the project will take more effort than an MVP.

No, it wouldn't require Java (thankfully).

The problem is the IO driver abstractions available on each platform are wildly different. Getting working filesystem driver code on Windows (7/8), Mac OS, and Linux is a non-trivial task that requires a lot of kernel mode hacking.

If you are willing to live with the performance impact, at least initially, you could use FUSE for MacOS/Linux. I don't recall if the Windows UMDF (User Mode Driver Framework) supports file system drivers or not.

Would you trust a full-disk encryption scheme running on top of a JVM? I sure wouldn't.

Your point is valid :)

All I want is a simple cross platform encryption program.

Maybe something that is LUKS compatible so it works straight away on Linux and with a simple GUI for Windows that makes it as seamless as possible? (Sits in tray, autodetects when a container containing device is inserted and offers to mount it?)

It's not hard (as such), yet no such program exists.

Try R10Cipher. It offers most of your requirements. www.r10cipher.com

Sorry for the multiples :-(

They are frightened that tptacek might say mean things about their hashing algorithms.

I'm not even in the security space and I'm sometimes afraid of tptacek's rebuttals to my comments.

Their hashing algorithms?

Or their node.js implementation of DNSSEC!

Contrary to popular belief I don't have a huge problem with Javascript. I'm just as likely to make fun of you for implementing DNSSEC in Haskell.

I thought you did for Javascript for crypto purposes, though, (ie, a pure node.js implementation), not Javascript in general, right?

My problem is content-controlled Javascript (or "browser Javascript", although that term is less useful what with browser extension Javascript, which isn't content-controlled).

I think most of us think a complete rewrite would take a lot longer than picking up the current source code and continuing it.

Seems reasonable. One thing I've learned from HN though is that brilliant and good at crypto are two very different things.

Agree. Unfortunately it seems to me that people on this site would rather create yet another jsframework.js or Flappy Bird As A Service as opposed to something like NewCrypt.

Pretty standard for the Hacker News crowd in my experience.

Such unwarranted and poisonous bitterness.

The people who publish easy stuff are typically new developers/entrepreneurs, simply people with less practice. There aren't all that many amazing, experienced developers with deep toolkits and skills. Better to commend people for trying and critique their work for what it is, than bemoan the lack of depth.

This sort of comment slings mud at the efforts of the young and inexperienced, when we should be trying to form a welcoming community that helps them grow. Our duty is to be supportive and help comb through the chafe to help find the diamond tech, content, and comments. That's the point of being here.

I agree, but there's another factor besides inexperience: time constraint. Many people have day jobs. Any projects that they do for fun or interest have to fit into their spare time. There's a limit to how ambitious such projects can be, and we definitely don't want to exclude them.

I think it's critical for HN to welcome a wide spectrum of original work. We want to see major technical achievements, of course. But we also want to see the minor one-offs. The bar for sharing your work on HN should be low.

The relationship between major work and minor one-offs is mysterious. Things that start off playful and trivial can develop in unexpected ways. Or maybe a success at something trivial inspires someone to a more ambitious next effort. If we want to have a culture of people sharing things they've made—which we do—we need to accept that most won't seem very impressive.

A good example is 2048. That game and its many variations weren't necessarily technically impressive. But the way in which a whole bunch of people riffed on each other's work for a few weeks—that was one of the most creative things ever to happen spontaneously on HN. If the game itself had been less trivial, I doubt that would have happened. The barrier to entry would have felt too high, so people without much time or experience wouldn't have gone for it. But because it was so simple, making one's own variation felt doable, and lots of people did.

I think there is different level of difficulty between the two things you just described.

And I'm pretty sure crypto is hard to work with and get right, and one mistake removes the purpose of software.

Of course it's a different level of difficulty. People seem to overwhelmingly prefer to work on easy, shallow projects as opposed to hard, meaningful ones.

Its not like there's some standard or minimum level of competency required to create an account and comment here. I think many expect this to be an enlightened and learned crowd of commenters when most people here are likely still college age or younger. Heck, I created my account back when I was still studying in university.

It is supposed to be a more enlightened crowd. If I wanted inane comments from only marginally-skilled people I'd read comments on reddit.

This is the sort of comment that belongs on Reddit.

Contrary to what you think, writing crypto things is interestingly hard, not discouragingly or too difficult. Anyone can write one and most coders would enjoy it. The trouble is that if you are not already good in security, your creation will have too many security problems and holes to be useful for anybody who is not NSA.

Are you seriously criticizing everybody else for not doing something you have never done either? That is pretty bold. Just take whatever your excuse is and apply it to them. That's generally a more realistic way to simulate everybody's aggregate view of the world.

People write jsframework.js or Flappy As A Service because jsframework.js is --- face it --- easy, and Truecrypt is hard.

A similar observation can be made about web-based encrypted chat systems versus encrypted block device drivers.

I agree 100%.

Oh my god, can you get me in the FBaaS beta?

Yeah, he gave the world a bunch of work for free. Total asshole, man!!1 Fuck him right in the ear!!

Srsly: TC always had a weird license and we accepted it because the rest of the product (seemed to) work so well. He doesn't owe anyone anything.

The author didn't owe anyone a filesystem encryption program. He still gave one to people for his own reasons. The fact that some people are pissed about the thing he gave them for free says more about those people than it does about him.

He doesn't owe anyone anything.

EDIT Fox must have good lawyers because I couldn't find Comic Book Guy complaining about how Itchy & Scratchy owe him because they've given him hundreds of hours of entertainment for free.

Its his software he can do whatever he wants with it.

Could anything be clearer than:

"I don't feel that forking truecrypt would be a good idea,[...]. I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of truecrypts current codebase."

?

It seems like a pretty good answer to me. If he feels that the code is bad enough that newcomers are unlikely to efficiently be able to work with it and not make it unsafe by making mistakes, he's probably correct.

I understand your point, but in that case why not to make that information public? All they had to do was to say on the website "We gonna rewrite TrueCrypt, stay tuned". Instead, we have this: "WARNING: Using TrueCrypt is not secure" or "use BitLocker" (really?) They chose to completely destroy the reputation of TrueCrypt. They are spreading FUD. They don't want a fork. I just find it really hard to believe that a 'normal' person with good intentions would do such a thing...

Last but not least, the audit that took place some time ago went fine so there are no reasons to consider TrueCrypt less secure then anything else (in fact, it's quite the opposite) and no 'rewrite' is necessary.

>"We gonna rewrite TrueCrypt, stay tuned"

Because they would be saying that they were going to do something that they had no plans to do?

>there are no reasons to consider TrueCrypt less secure then anything else (in fact, it's quite the opposite) and no 'rewrite' is necessary.

You have a different opinion than the one of the authors, and you're entitled to it. It's not nice to attack someone who has a different opinion, though, especially when it's about a piece of software that they developed, and offered free of use for many years. Their opinion may be more informed than yours, but it's at least as informed as yours.

He didn't forbid anyone from using it however they want, you just can't do whatever you want and call it TrueCrypt, or distribute whatever you do with it without saying it's TrueCrypt-derived. I've never understand why the "Free and Open" software community is so opposed to attribution clauses, it seems only fair to give credit.