Slashdot Mirror
TrueCrypt Author Claims That Forking Is Impossible
An anonymous reader writes On a request from Matthew Green to fork the TrueCrypt code, the author answers that this is impossible. He says that this might be no good idea, because the code needs a rewrite, but he allows to use the existing code as a reference. "I am sorry, but I think what you're asking for here is impossible. I don't feel that forking TrueCrypt would be a good idea, a complete rewrite was something we wanted to do for a while. I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of truecrypts current codebase. I have no problem with the source code being used as reference."
./ editors must not have had their coffee yet.
It would appear that the intended meaning is 'impractical'. The code is available, and the original project declared itself dead, so forking is totally possible; but the author believes that it would probably be a better use of time to use the existing project as a reference for building a new one, rather than get sufficiently familiar with the old one that you can (safely) start modifying it.
I don't know if it's true or not; but it's a much less radical assertion.
His answer seems to mean it wouldn't be his preference, rather than being impossible.
did you forget to take your meds?
What has happened with Truecrypt, I mean from a psychological perspective. It would appear as though the team had a nervous breakdown going pear shaped rather quickly. Certainly since the source is available it can be forked, screw that just rewrite it. There's not that much there.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
The article source is from pastebin. Are we really supposed to give this any merit? It's pretty obvious that the authors won't sanction anything related to the project (or did we forget the final cripple commit?)
He says that this might be no good idea ... but he allows to use the existing code...
Holy crap...
Seriously, Slashdot has "no good" editors...
Come on guys. Seriously. Invest two seconds into reading and fixing the sentences. I don't think we're expecting rock solid perfect grammar but this is embarrassing...
Easy to be brave when there's not a TLA breathing down your neck.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If you look at just about any abandoned code base ou will find that the original authors claimed it could not be maintained or should be re-wrriten from scratch. They always wrong and there are usually (better) developers who come along and prove that. Remember when the GNOME desktps said GNOME 2 could not be maintained and they had to scrap everything to make way for GNOME 3. Now the MATE developers have not only carried on the original GNOME 2 code, but thy have also cleaned it up a little and modernized it. Next year they plan to port GNOME 2 to the GTK 3 toolkit, proven the GNOME developers were wrong.
The same issue comes up with many big open source projects. The original devs walk off and claim their code cannot be salvaged or maintained. It's always too big or confusing or complex, they claim. But someone almost always comes along and proves the code still works, can be updated and the fork usually does well.
The TrueCrypt author is obviously incorrect, the code can be forked and maintained. And it likely will be, probably by people who have more time/energy than the original team.
Reading between the lines here, it seems fairly probable that Truecrypt has either
a) Very serious security bugs, or
b) Had backdoors introduced by the NSA.(Does Truecrypt use elliptic curve cryptography?)
In either event the code is basically tainted and shouldn't be used for any future projects.
The vague and sometimes bizzare nature of the statements from the Truecrypt dev team, including this one, lead me to believe that they have been placed under a standard NSA gagging order and have decided to burn Truecrypt rather than see it be turned against its users. Comments like "Forking is Impossibe" appear to be an open code for communicating that they are essentially unable to communicate, but that Truecrypt is no longer a trustworthy piece of software.
Reading though the Lavabit case, it's clear that those placed under NSA gagging orders have very, very little room for legal/media maneuver, but nevertheless still retain the freedom to walk away from their projects and tell others not to use them. Such actions appear to be the last defense of cryptographers in the US, and I think that is what we're seeing with Truecrypt.
May the Maths Be with you!
Maybe some government agency inserted some code there, and the author knows it. That's why he recommends rewriting from scratch, because even he doesn't remember where the code is injected, and it's probably very hard to trace.
If we're going to re-write it, do we continue with the ongoing audit? Do we hold back on paying for more testing so we can audit the re-write?
Finally had enough. Come see us over at https://soylentnews.org/
If he suspects the code has a vulnerabitlity, he doesn't want it copied.
Seriously, people, save yourself the time. You'll just also get a letter from the NSA and either have to include their backdoor or drop the project.
And I sure as hell don't want to be the one who did the right thing only to see it going to waste because someone else didn't.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
This is a pissing war. Both sides may be sincere and well intentioned, but it's still a pissing war. Here's a manager type summary. I'll use TC to represent the TC developer who responder and Forkers for the person representing the people who want to fork it.
Forkers: We'd like your permission to fork your code and get the rights to it. We could just fork it without your permission and others no doubt will if you refuse to comply. We want your trademarks and your OK to put the forked code into a different license then you used. We've started looking at your code and while we do agree that there are problems there that desperately need to be fixed, we feel strongly that fixing your broken code is a million times easier than writing this from scratch. So will you play ball with us?
TC: Our code is so broken that you need to start from scratch. That's why we abandoned it - didn't think it was possible to fix without doing a complete re-write. So no, we're not going to "play ball".
As far as we know so far, Truecrypt hasn't been compromised. So ending use of it might be a victory for the NSA and their kind. And all they had to do was sow some seeds of doubt.
I don't think it's unreasonable to conclude that some vague, yet menacing government agency has compromised the code and the developers are unwilling to see what they worked for burned to the ground. I mean, 15 years ago, this would have sounded like the rantings of a paranoid schizophrenic, but with all that's come out about the U.S. government recently, I think it's perfectly rational. Given the level of security TrueCrypt has the potential to provide, and the level of oversight the U.S. Government wants over both foreigners and citizens alike, I would honestly be surprised if TrueCrypt wasn't compromised long ago.
Maybe the goals of this vague, yet menacing government agency are pure and wholesome. After all, TrueCrypt would absolutely benefit those organizations trying to keep their activities secret from authority. But we'll never know because of the veil of secrecy behind it.
-Arthur
Cave ne ante ullas catapultas ambules
It's more likely that the author is the victim of a National Security Letter, and is obliged to say things like this to discourage people from using TrueCrypt or forking it. Which ever agency got to him must have known that this was likely to happen, and he is probably in it knee deep after putting lots of not-so-subtle hints on the revised homepage.
The 7.1a source code is being audited. There may be issues with the code base, but at least we will soon know with reasonable confidence if it is secure or not. Starting a new project would require a complete audit from scratch to get that level of confidence, and it is likely that at least one of the replacement projects is an NSA shill with backdoors installed from day one. The very fact that they went after TrueCrypt gives us some confidence that it is resilient to their attacks.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Lavabit, NSLs, etc are FBI, not NSA. The NSA may have found vulnerabilities, may have even hacked his computer and modified the source code, but they don't dick around with NSLs or gag orders.
Source: I'm a spook.
Reading though the Lavabit case, it's clear that those placed under NSA gagging orders have very, very little room for legal/media maneuver, but nevertheless still retain the freedom to walk away from their projects and tell others not to use them. Such actions appear to be the last defense of cryptographers in the US, and I think that is what we're seeing with Truecrypt.
Just rhetorically speaking, and based on these situations, I'd really like to know just what kind of punishment can the NSA hand out, anyway. Is the guy under legitimate threat of being renditioned to some black hole never to be seen again? He can't be tried in a fully open court where the government has to essentially confirm his story in order to convict him. Even if the government convinces a judge that he's committed some secret offence of a nature that cannot be disclosed, that's still a form of confirmation. So does he get sent to a star chamber to be tried, convicted and never seen again? Can they go Manning on him -- he's not revealing government secrets he learned on the job, right? (Or did he?) When the government starts actually locking people up for dissent, it's game over, isn't it?
I am not a crackpot.
Hi folks, I have wondered about this.... If you have a product like TrueCrypt and get a National Security Letter telling you that you can't talk about it, does that include your attorney? I seem to remember that someone decided to sue NSA over this... Just curious...
He says:
"I am sorry, but I think what you're asking for here is impossible."
As a developer, he uses the term "impossible". Nobody says
"impossible" in a development framework. You could
say "difficult" or "expensive" but not "impossible".
He says "impossible" because he is telling us in
specific terms:
It is "impossible" to use the current code base because
it has been compromised. He can't talk about it. He is
under court order or some fucking thing.
Since he cant tell us where the compromise is
he says fuck it all and start from scratch.
He is very specific.
Look, if the developer of an encryption product
says the product is not secure and it is impossible
to fix, I take that as:
"Stay the fuck away from this thing".
To be forewarned...
With few exceptions, rewrites are a bad idea. They only make sense when you need to fundamentally change the architecture, and even then it's often better to refactor heavily. Almost without exception, whenever someone says "Oh, it'll be easier to start from scratch", they're wrong. I understand that the TrueCrypt codebase is something of a mess, but I'm still skeptical that a rewrite is actually a better choice.
My opinion is the exact opposite: rewrites are often better when reaching a certain codebase size. The main reason is that existing functionality can often be put into a better shape by taking the big picture and adjusting everything according from the experience of the existing code.
The idea that rewrites are bad (that is often taught in programming classes) is mostly economical: it is less economical to do a rewrite rather than patch another level of indirection somewhere in the code tree. It requires more effort, a thorough understanding of the existing codebase (which often doesn't exist at all when code reaches some size, depending on _what_ the code does) and it requires a time gap between the releases.
But all these problems are fundamentally economical. But doing a rewrite can often be more economical, it's just that doing a patch is easier to quantify in money than a rewrite that will simplify patching/upgrades in the future and avoid fragile bug promoting messes.
Refactoring is essentially a "running rewrite" where parts of the code is changed while keeping most/all other parts intact or slightly changed. It decreases the time gap problem but in most cases require more effort than a rewrite while making many types of improvements hard or impossible.
A paranoid man is difficult to surprise.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
You missed an explanation - the TrueCrypt devs determined that the community code audit of TrueCrypt would eventually turn up backdoors, or spotty code in places so bizarre it would have to be intentional - and, possibly combined with a National Security Letter, the debs decided to just burn the house to the ground instead of allowing the government to repeatedly burgle it.
THIS SPACE INTENTIONALLY LEFT BLANK.
I used to feel the same way, but over the decades experience has taught me otherwise.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
They say it is better to kick someone out of a plane than let these people have a day in court.
--Edward Snowden
http://www.theguardian.com/wor...
I do not read that much into it.
I have many code bases out there. However, I would not recommend people build on them. The team that knows how it works no longer exists. In many cases even if you could get them back together they have not seen the code in years.
Sometimes it is better to throw it out and start over. Using the existing code as your test for features and build yourself a design you understand as you are the one who will be working on it.
Now you could also refactor. That in many cases takes as much work as rewriting it. As that is exactly what you are doing.
I have seen both ways done many times. Both work. But if the orig author says 'i wouldnt bother' it is usually worth at least listening to his advice.
How would you know it was genuine without consulting a legal professional? I can download the NSA logo from Google Images, find their address from Wikipedia, and write "You should stop doing this thing or we'll invite you to stay at Guantanamo Bay Care Home for the Politically Undesirable. Oh, and where I said 'invite you to stay at' replace it with 'put you in a 4' x 2' x 2' hold-all and ship you freight to'."
Someone should start sending fakes to random US addresses, just to see what happens.
Finally had enough. Come see us over at https://soylentnews.org/
I don't see the problem, codebase is old, in some part flawed, use it for reference and build and new clean stronger software....end of story....
A security letter could ask for a lot of things but it would be a bit strange for it to demand that the source code license not be modified. To make that of any value the security letter would also have to demand that the group of developers enforce their copyright. That is easily tested. Fork the code, create NewTrueCrypt and put it up on a website. If a cease and desist letter appears then you are, perhaps, correct. If not, you are likely incorrect.
One thing about Truecrypt that always impressed me was how well it worked with Windows -- containers with drive letters, whole disk encryption, etc.
If you were to recreate it, what would be the hardest part -- doing the encryption or doing the OS integration bits? I assume doing encryption securely (ie, not leaving keys or passphrases hanging around in memory or written to swap files) is non-trivial, but I also assume that integrating well with Windows is, too.
Does Truecrypt use elliptic curve cryptography?
No.
In either event the code is basically tainted and shouldn't be used for any future projects.
Given that the author has sworn it off, thatd probably be wise.
The situation is probably what it was stated to be, that the developers do not understand the code and its more trouble to try to unravel a poorly written software project than to do it over again. THis is a common problem with open source. Software code is NOT self documenting, but open source people think it is. To really understand a big project in reasonable amount of time you really, really need good documentation and an overview of the system
Its not even remotely crazy at this point. TLAs are strongly suspected of having backdoored Windows 2000, OpenBSD's IPSec stack, and the PRNG used by RSA. There are some slides floating around on the internet indicating that there is already a backdoor in Bitlocker.
At this point you would have to be crazy NOT to expect a TLA to have an "answer" to Truecrypt-- thats exactly why theres a code audit being done.
I dont think he has to "discourage" people from forking it. AFAIK the license its under means it cannot be forked, especially not without his blessing.
1. Evidence seems to point that the main developer is in Europe. So, an NSA NSL doesn't seem (to me) to be a likely factor. 2. Evidence points to the history of the code perhaps being legally murky. But from what I recall of the forum discussion nearly a decade ago, most of the murk wasn't due to the code origins, which appeared to be on the up and up, but due to the legal threats/actions of a company that thought it could prevent a fork from *before* buying code/hiring the developer. That's IIRC, of course, I've seen reporting all over the map on this issue. Also, supposition: there may have also been verbal promises between the dev(s) and outside entities about what might trigger more legal issues. 3. Evidence points to English being the main developer's second language, so the conspiracy theories base on awkward sentence construction are probably just that, theories. 4. Evidence (now gone, due to the tc forums being removed) also seems to point to the main developer having strong feelings about control over the main code line and trademarks for a long time. Some of this seemed rational (wanting to block a plethora of backdoored versions being deployed) but some of this seemed personal. Most devs have been there, some have matured and learned to let it go. Conclusion: the simplest explanation, to me, is that the main dev wants to the code dead and buried so that he is entirely free of any future legal, ethical or emotional consequences of it continuing.
I'm seeing a Streisand effect. There is so much suspicion about TC's abrupt ending, especially after the code reviews found that it is a clean product, that more people seem to be using because they feel that it was killed by some powerful party.
TC is the only cross platform product out there that gives plausible deniability, is open source, and has been through an audit. The only thing against it are rumors about backdoors, none found.
They could have said something like "No Such Action should be taken with regard to our code and you Can't Implement Anything based on it. You might Feel Better If you rewrite everything from scratch."
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
When it comes to security, one must always error on the side of caution. There are very strong signs and signals that there is a problem with Truecrypt. Those that don't heed that warning are placing themselves at risk.
The default position of everything is: insecure until proven otherwise. If there's a good chance something is insecure, then we assume it is. We don't want to error in the other direction because the implications are too great if we are wrong. This is where we are with Truecrypt. Those throwing caution to the wind - at this point - are doing themselves a disservice.
--- Redefining "OS integration" to include "OS and boot integration", the short answer is: the boot process, hands down. You can model a new app based on TC's approach for OS-level (container/partition/disk) encryption, and you can do the same for MBR boot/system disk encryption, but now that everything is moving to TCG-TCM/UEFI/GPT/etc. it's a lot more complicated. -- Some history: IIRC from the TC forum, the TC's developer had issues finding a public API/method in the MS docs that could be used to pass keys and boot control from the MBR/bootloader to the OS and tc driver shim. There were third party apps out there doing it, but there didn't seem to be a documented way to do it, and the tc devs wanted to avoid fragile hacks to get it done. -- Microsoft actually responded to the TC devs by either publicizing a private API or by creating an official one. Again, this was back in the MBR days. -- With UEFI/GPT, trusted boot, etc., this part has become a lot more complex. I'm not sure what Microsoft's responsiveness would be on pursuing an official UEFI/GPT API, but I wouldn't be surprised if it's something along the lines of "Just use Bitlocker, it does this already."
This.
Try blowing the whistle on something. Revel in satisfying your moral obligation and the feeling of righteousnous. It will last until the first threatening letter from a lawyer arrives. Then you'll see what you're made of. Chances are good that it's not steel. Until you've experienced it, you won't know.
Just about any government organization or better than medium-sized private entity has the resources to crush an individual with very little threat of recourse. You really can't imagine the kinds of crap they can lob. If you are thinking of blowing a whistle, be very careful. Read up on the subject (Google for "how to whistleblower"). Absolutely DO NOT try to use internal channels. There are organizations that try to support whistle blowers, contact one (anonymously) and see what reading material they can give you. Make sure your nose is absolutely clean. Try to find cases of similar acts of whistle-blowing in your legal jurisdiction. How did they turn out for the whistle-blower? Probably not very good. Do everything right. Make sure you have enough evidence for an iron-clad case (without actually stealing anything). And wait until you have some distance. If you can keep the perpetrator(s) from figuring out your identity, absolutely do so. You will save yourself a lot of grief. This means you have to keep your mouth shut and trust nobody. (Note that I'm posting anonymously.) You won't be able to vent to anyone, especially co-workers. This is much harder than you might think. If you like to talk, you'd best just forget what you've seen. If you can time your actions so they hit while the perpetrator is under pressure for other problems, so much the better. Before you pull the trigger, think long and hard about the affect this will have on your loved ones. Consider supporting an anti-corruption organization to satisfy your need to do good rather than risking yourself.
Yes, it's really that bad. The sort of folk that deserve to be found out are more entrenched than you suspect. They are willing to go to extreme lengths to protect themselves. The problem almost definitely is more widespread than you think. The way it often works is that there is a web of wrong-doing, where one fellow's previous mistakes are used as leverage for silence/support by someone else. It makes for a kind of club. Many members of the club will have had one or more whistles blown on them before and have strategies for dodging and attacking the whistle-blower.
And that's just if you are whistle-blowing on a run of the mill organization. Going up against the likes of the NSA, the DOD, or the CIA... The TrueCrypt authors have all of my respect for shutting the project down. It was an act of bravery.
Whoosh!
Well.. maybe. Or Maybe not. But Definitely not sort of.
Rewrites often work well if the original goal for the software has morphed over time, so that its overall structure just no longer makes sense. In other cases codebase does contain a ton of good tribal knowledge that's often lost and has to be relearned during a rewrite process. Confusing things is the fact that in many areas the tools available to developers now (libraries, etc) are far more powerful than they were even 4-5 years ago, so removing code that isn't necessary to meet a business need can really help.
tl;dr: its complicated, and it all depends.
You're special forces then? That's great! I just love your olympics!
Matt Green, the cryptographer leading the TC audit effort, had established contact with one or more developers (somehow) over the last year or so.
So, to most of us, the TC developers are still anonymous, but not to everyone...
The Guardian reported on a hidden Latin message: TrueCrypt probably didn't leave a Latin message alerting users to NSA spying. I'm not so sure about their in-headline conclusion, though.
They quote this comment on Wikipedia by 'Bardon':
The Guardian article rebuffs this with: "In fact, "uti nsa im cu si" is meaningless in Latin - except to Google translate, (mis)translates it to the message Badon discovered."
But isn't that enough? It's a hidden message; it doesn't need to be correct Latin as long as the point gets across. If you put into Google Translate right now, you get "If I wish to use the NSA". Unusual that it's been changed slightly, but still expresses the same message: The NSA has compromised TrueCrypt.
I'm not one for conspiracy theories, but this entire TrueCrypt saga has been bizarre. Obviously something happened beyond "the task of maintaining a widely used cryptography program just became too much work" or else why not just say that?
As far as we know so far, Truecrypt hasn't been compromised.
No, you're wrong.
From the TrueCrypt website:
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
WARNING: Using TrueCrypt is not secure
It may not use the explicit word 'compromised', but that says it clearly right there. TrueCrypt is compromised, whether a TLA did it or not.
It very well could be "code speak" (pardon pun) for; "yes our code is compromised, no we are not allowed to talk about it, end communication".
Then again it could me less complicated than that, and taken at face value they could be saying; "Our code is a mess. Fixing it would take more effort than we are willing to expend for this project so we ended it. You are welcome to try, but we would recommend you just start from scratch as it contains many fundamental problems."
It is too bad, I've always considered it the defacto standard in encryption. I am not a huge fan of the idea of MS being my provider of encryption with bitlocker, though I have heard some good things about it. Then again it isn't exactly free either.
The Slashdot tinfoil hat part of me wants to believe the NSA story, however common sense tells me it is just another open project that was led by a dedicated few with little resources that became too much to maintain over time. That said, they were rather elusive about it in the end, so who knows. Then again that could be a professional record thing, liability, or legal... plausible deniability limiting personal liability sort of thing.
Yeah, there was an article a few years back over this where attorneys was even't allowed to talk about the laws the client "officially" broke because it was against the law to acknowledge those laws even existed in the first place! WTF?!
I'll be darned if I can remember the link ...
NSL is just as TLA as the rest of the them. As a spook, you gotta understand that you're in with all the other spooks whether you like it or not.
Also if they find a big flaw, the reason for burning the project, announcing that it exists and what it is, opens it up for exploitation.
Knowing it is there, large enough that it is not fixable within the current state of the code or at least not easily (say without starting from scratch), might make them abandon the project, yet be quiet about the actual details as to why. If they say how it is broken, and expose peoples data to exploitation, are they going to get sued? Likely there is wording that indemnifies them, but that might not keep people from trying. Just defending yourself can cost money. Also I have seen plenty of situations, where people know they are in the right legally, but choose a non-confrontation path, as it is best to avoid it altogether if at all possible, taking the lowest possible risk as they can, and if possible I am pretty sure lawyers would suggest this course of action if it is an option..
My thoughts exactly well said.
Yeah, sounds fun. Why don't you try it and let us know how it goes?...
Peter predicted that you would "deliberately forget" creation 2000 years ago...
"I am sorry, but I think what you're asking for here is impossible. I don't feel that forking truecrypt would be a good idea, a complete rewrite was something we wanted to do for a while. I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of truecrypts current codebase.
I have no problem with the source code being used as reference."
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
strongly suspected
Is there evidence to support any of these assertions? Just because it's less "unlikely" doesn't mean it's "true."
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
I'd really like to know just what kind of punishment can the NSA hand out, anyway. Is the guy under legitimate threat of being renditioned to some black hole never to be seen again?
The CIA rendition plane was waiitng for Snowden. When Joseph Nacchio (Qwest CEO) refused to play ball with NSA, they set the SEC on him with some bogus charges and then refused to allow him to defend himself in court by classifying the evidence.
When the government starts actually locking people up for dissent, it's game over, isn't it?
Only if people do nothing to stop them. So far, Americans seem as willing to fight as the 30's Germans.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The hardest part is getting people to trust it.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
How could he stop people forking it? If he were to sue them is identity would be revealed.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
You just very succinctly expressed more insight than 99.9% of this discussion page. The only thing I would add is that the cease and desist letter would be very illuminating. It would have to give a face to the anonymous developer group, and give New Guys a chance to sink their teeth into that face in court. Let's see what happens when an NSL muzzle competes with the right to question witnesses in court and have the questions answered truthfully under penalty of perjury.
Of course New Guys might be operating in a jurisdiction where they could just file the cease and desist letter with today's garbage.
I dont think anyone is 100% sure on any of it, but as I recall...
* There were a number of indications that the OpenBSD IPSec flaw was intentional. There were also rumors flying around about an informant who claimed to have been involved in the backdooring
* Windows 2000's debug symbols included reference to an _NSAKEY. Microsoft provided an explanation for what it was, but of course theyre not exactly a neutral party.
* AFAIK everyone is pretty sure that the RSA PRNG backdoor was intentional, and orchestrated by the NSA.
* The Bitlocker "backdoor" is an unsubstantiated-but-not-inconceivable rumor.
Code review did not find it to be a clean product. They simply found that the Windows binary that was distributed could be produced from the source code. IE there were no extras in that bin. Whether the code itself has crap in it is still at question and is being audited.
Silence is a state of mime.
And how can he prove this?
This is a common problem with software.
I daresay you could also state "on-disk structures completely interoperable with TrueCrypt".
At this point you would have to be crazy NOT to expect a TLA to have an "answer" to Truecrypt-- thats exactly why theres a code audit being done.
How do we know the TLA doesn't have an answer to "publicly announced code audit" ?
Who is doing this audit... what is their process?
What happens when the person responsible for conducting the audit of module X, gets a national security letter ordering them to "Not report finding anything wrong" in their audit results with "such and such" file?
THis is a common problem with open source. Software code is NOT self documenting, but open source people think it is. To really understand a big project in reasonable amount of time you really, really need good documentation and an overview of the system
Because this is a non-issue in closed source commercial projects.
Talk about being narrowminded and judging a group of people by the bad apples.
Impersonating the government worked out great for that guy in Peoria.
Tangentially related: If you Google "peoria mayor" it shows a picture of Jim Ardis with a hitler mustache.
Frankly, nothing could concern me less than making it work well with Windows. I am only interested in using it with an open source OS. I don't care in the least whether a hypothetical recreation of TrueCrypt works with Windows at all. Mod me down if it makes you feel good. It's only an personal preference.
In the very near future 'coming out' won't be the declaration of your sexual orientation, but the refusal to knuckle under to the fascist pricks of the Spook-Industrial complex via an NSL.
Yes, it will be hard, yes, it may even be prison time but this is the whole point of repressive intimidation tactics: the hope of the power-mad that individuals stay cowed and powerless, not unified and unbowed in the face of true oppression - that actual freedom isn't free.
Can you imagine if a project of TrueCrypt's successor got an NSL and _every_ person even remotely connected to the project all appeared together in the live-streamed press conference exposing and denouncing FedGov... they're gonna prosecute all of them? All together? In a show trial, perhaps? Cockroaches hate exposure to the light.
Please, please mod parent up.
Lavabit, NSLs, etc are FBI, not NSA. The NSA may have found vulnerabilities, may have even hacked his computer and modified the source code, but they don't dick around with NSLs or gag orders.
Source: I'm a spook.
Which kind? Black dude or a spy?
The first statement is a tautology and the second is unconfirmed and could just be FUD-mongering to discourage us from using a product the TLAs haven't cracked. If you give up a privacy tool every time someone merely claims to have subverted it, soon you will have no tools left. By the way, your home is not secure; I've subverted it. Good luck.
Any piece of software developed by US citizens, companies, foundations, etc. is no longer trustworthy. The US is dead as far as secure software is concerned.
The geek's insistence that the US is hopelessly corrupt and salvation is to found elsewhere is ridiculous.
Every country keeps watch over its, neighbors, friends and enemies alike. Alliances are never permanent, only interests.
When performing risk management, if there is any hint of doubt in the security of a system then the system must be assumed to be insecure and compromised until such time it can be proven that the system is fully secure in all use cases (a near impossibility in itself). This means that if there's a rumor of a leak in a mission critical system, regardless of evidence or lack there of, a responsible organization should immediately sandbox the system and test it for holes and apply countermeasures if any holes are verified in the sandbox.
Note that countermeasures could be anything that extends from software patches to hardware firewall to complete system decommission and redesign.
Code review did not find it to be a clean product. They simply found that the Windows binary that was distributed could be produced from the source code. IE there were no extras in that bin. Whether the code itself has crap in it is still at question and is being audited.
Binary Reproducibility wasn't a goal (or even attempted) by the audit project - that was done by somebody else.
The audit project didn't go through the entire TC codebase, but covered a lot of important areas. They found some issues here and there, but nothing they highlighted was especially serious - i.e., no cold-attack vectors, which is the important thing to guard against (anybody with physical access to your machine would be able to dump keys from memory, Game Over).
There is also the fact that if someone decided to take all of TC's code, cut and paste it, and make it BSD licensed or GPL licensed, there is nobody that will step up to enforce TC's license. Is there a person that the code belongs to? Will the TC Foundation have the resources to get lawyers for it, even if it is just for a DMCA takedown notice?
This may be a case where IP infringement can be done, just because there is nobody who is truly owning the code and can step up to defend it.
It's a 'that depends' situation.
I've worked with a lot of N-tier applications that are distributed across multiple platforms. Tweaks are possible because they can extend something (so is some cleanup) but rewrites aren't because they cannot be guaranteed not to reintroduce bugs (at release) into complex ecosystems that have worked hard over the years to pound those bugs out.
You talk about not being able to understand a code base and this somehow making re-writing better. If you can't understand a code base, how can you rewrite it so that it will do the exact same thing and be a slot-in replacement for the existing one? In any complex system, you can't do this and know you won't bollix up some obscure bit of functionality only one client is using. But that client, if it is, say for instance, a Telco...won't take that very kindly.
A re-write is fine if you are going to issue a totally new product that does not have to manage 1 for 1 substitution into a running ecosystem. Otherwise, very minimal and careful tweaking and cleaning up is better.
I've actually seen pieces of code running in million dollar software systems that say things like "This function is a black box. Don't touch it. If you touch it, you will break it. If you break it, someone will be hunting for your head."
Now, a rewrite where you DO understand ALL of the detail of a code module AND you can justify the rewrite in terms of ROI to those who are going to fund the rewrite can yield significant value. It can also get stuck and show you didn't know ALL of what a module did and you can fark up a whole system.
Sadly, on many major software systems, the only true test platform is THE LIVE CUSTOMER PLATFORM. Any other test platform is generally making simplification, assumptions, or leaving out some functions.
I find the time a rewrite is economical is usually when, without the rewrite, the current software cannot scale, perform, or otherwise do what (now) needs to be done. At that point, the cost of not doing it is not implementing something or not meeting a required performance threshold to be marketable. At that point, that cost is effectively sky high in most case, and the cost of reimplementing is lesser, even if it is significant.
I've worked on projects for: Financial, Telcos/Cell Providers Internet NMS and Policy systems, Public Safety and Police Dispatching, Networked Military Trainers, Massive HR systems, Massive Online Gaming, and nationwide Point of Sale systems. Rewrites have usually been a disaster for most of the companies I've worked with.
Because noone wants to start a gratis OSS project with the spectre of a lawsuit hanging over their head?
Those are pretty valid concerns.
At this point if you're looking for full disk encryption, the most obvious choice is Bestcrypt. Its been around for ages, it operates very similar to Truecrypt, and its notably not incorporated in the US but in Switzerland.
I think that one is easy... just ask him "Have you ever received an National Security Letters?". There are only two responses to that question: "No" or NULL.
-- I was raised on the command line, bitch
Not secure in what context? Not secure to stop the NSA? Not secure to stop the average hacker? Not secure to prevent company property from being exposed to the public when a laptop is lost?
The only thing I would add is that the cease and desist letter would be very illuminating. It would have to give a face to the anonymous developer group, and give New Guys a chance to sink their teeth into that face in court.
Assuming, of course, that the C&D letter comes from the original authors, and not shills set up (and funded by) whatever TLAs.
Coffee-driven development.
Half Life 3 confirmed!
Hail Eris, full of mischief...
E pluribus sanguinem
Mod parent up - I'm replying here, so can't use mod points :-)
Passing the decryption keys around in BIOS-style boot is somewhat dirty - haven't perused the TC source, so I don't know how they specifically do it, but it'd probably be along the lines of leaving the key at some fixed memory location, and let the Windows boot-time driver read it from there. UEFI drivers have a whole new way of booting the system, so you'd need to adapt to that. It's probably doable, and probably doesn't even need big voodoo - but if you've been working on a codebase for ~10 years, don't need UEFI support yourself, and probably have a family to look after now... it'd be a darn big task implementing. While UEFI stuff can be programmed in C rather than assembly and has SDK and documentation, it's quite a different world.
If we ignore (or postpone) encrypted boot volumes, however, I'm pretty sure that very large parts of the TrueCrypt codebase could be re-used - and at the same time, the really archaic build environment requirements could be dropped.
Coffee-driven development.
Frankly, nothing could concern me less than making it work well with Windows. I am only interested in using it with an open source OS.
How awesome for you.
Some people believe that privacy is a right and work to ensure that as many people of possible have means of protecting that right. I say thank you to those people.
the developers do not understand the code and its more trouble to try to unravel a poorly written software project than to do it over again.
Don't remember what podcast I was listening to, but someone was saying that he read the source code and found it to be *beautifully* written! Although I certainly have no skill to confirm this, "beautiful" is not an adjective to be used if he thought it couldn't be understood or needed "unraveling".
Look at the tomato! Isn't it sad? He can't dance! Poor tomato!
"As far as we know so far, Truecrypt hasn't been compromised"
The message from the originator may be covert side-channel communication that this is not the case.
Ah, but what if the forkers are also anonymous? John Doe vs John Doe? :)
Refactoring can eventually lead to an almost complete rewrite but the point is that you're keeping most of the logical structure. Complete rewrites often end up reinventing the wheel badly and missing edge cases which were accounted for in the original code. Rewrites make assumptions that often prove to be untrue.
Here's an oft linked article
http://www.joelonsoftware.com/...
You absolutely have the right to consult with an attorney before you are investigated or accused of a crime. A big part of an attorney's job is showing people how to accomplish something without breaking the law. Your notion that the government can prohibit me from consulting with an attorney about a lease I am about to sign because I haven't been accused of a crime has no basis in reality. You are simply making up your "fact: that "you may not consult with an attorney about an NSL". NSL's have been the subject of multiple court cases and in each of those court cases attorneys have been involved.
"Librarians' NSL Challenge" (May 26, 2006)
https://www.aclu.org/national-...
https://www.aclu.org/blog/cont...
The US legal system has faced the unconstitutional NSL issue.
Once in light the press and in open court the gov just "withdrew its demand".
Domestic spying is now "Benign Information Gathering"
Elliptic curve cryptography is not a problem, it's the Dual Elliptic Curve Deterministic Random Bit Generation standard that is a problem. Elliptic curve is a very big family of cryptographic tools.
With the number of tame brands hardware and software layers helping between your keyboard and your secure crypto software? :)
You almost want your own file system and OS
http://www.theguardian.com/wor... (7 June 2013)
Experts have had a while to think about what is under and around their secure crypto projects on the big consumer, prosumer and 'free' OS.
Domestic spying is now "Benign Information Gathering"
More like you're too busy chasing conspiracy theories to know when you're being mocked for it.
Hail Eris, full of mischief...
E pluribus sanguinem
"number of indications " ,"pretty sure ","unsubstantiated-but-not-inconceivable rumor","rumors flying around about an informant "
Sounds like enough proof to me.
Wait till you get a load of us Aussies , cobba!
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Honestly, I think that's one of Joel's poorer articles. He writes a lot of good stuff, but he's not always right - his views on giving programmers their own office in isolation of others runs in complete contradiction to the reasons for success at many startups that have grown into the big boys like Google, and Facebook for example not to mention many such articles including the one you linked are ancient now (this one is 14 years old) and understanding of problems changes. He makes a lot of claims in this particular article without really any founding:
"It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time."
This is complete nonsense. When you've worked with a codebase for a while you begin to understand it's deficiencies, sometimes they can be resolved with a simple refactor, but other times there's a more fundamental problem with the whole underlying architecture, and at that point a rewrite is a sensible option.
"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95."
These are mostly symptoms of why the codebase should be re-written, if it's full of hacks, sorry "bug fixes" like this then it's a sign that there were design deficiencies from the outset. You shouldn't have LoadLibrary calls everywhere to fix things because you should've had a platform abstraction layer which hides all that away in one comfortable place. Worse, because the codebase is full of such hacks, the maintainability of the codebase would be atrocious. You'll be throwing away hours trying to understand the implications of changes on these hacks, and making these hacks work with changes, when a clean design learning from the issues in the original codebase would simply let you just write your changes without any worries about upsetting these hacks. He claims "Itâ(TM)s harder to read code than to write it." - that's only true if your codebase is a complete mess and needs rewriting in the first place.
Worse, because your codebase is full of hacks and unreadable code, the potential for difficult to track bugs increases drastically.
Which isn't to say I think rewrites are always a good idea, but I think his examples are poor - for every example of failed rewrites, there is at least an example of a successful rewrite. He's right that if you have a shit dev team that doesn't understand the problems the software is trying to solve well that a rewrite will likely fail also, but that's more a fundamental problem with having a shit dev team than any inherent problem with rewrites.
Most the time consumption in writing software is understanding how to solve problems, the reasons for needing a rewrite are generally architectural. It's not uncommon to be able to define a new architecture and move across knowledge of problem solving or even methods or classes to do so into a completely fresh architectural design. Unless your developers are an army of incompetent hen-pecking typists then writing code is the quick part.
So again, rewrites are not always part the solution, but if you're designing a more flexible and future proof architecture and going in with a development paradigm change, such as writing the new version in TDD, then you can most definitely end up with something that's higher quality, quicker to make changes too, and performs better resulting in a clear net gain in overall cost due to the drastic reduction in time spent bug fixing and g
This isn't so much 'giving up a privacy tool' as having the latest version of the privacy tool be stripped of the ability to encrypt and then released with the wording that it is not secure. The actions that will prevent a user from using this software were not made by the users. The choice was made by ... who, exactly?
Actually, NSL is a TLA for National Security Letter.
Or as that other gentleman pointed out, an initialization. Where TLA is an initialization of "Three Letter Acronym" where I seem to actually mean initialization, so..
NSA is just as TLI as the rest of them.
Regardless, that would be a bad idea. There are enough doubts about the security of the product now. Ideally there will be an OpenCrypt cleanroom clone of the product that is truly open source (not the almost open source license of TrueCrypt). There should be structure to the product: open code audits and security reviews, not some vague promise that it is secure.
Another critical feature of the new product should be a geographically diverse set of developers. The last thing we need is the FBI or NSA silencing the project. Maybe U.S.-based developers would be gagged, but with developers in multiple countries and well-placed canaries, that should be designed to backfire relatively quickly.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
I don't think so. When you do a rewrite, you have to uncover all use-cases that the the original software was covering. The software was doing A,B as well as C, D, E. When you do the rewrite, you will focus on the truly important use-cases A & B, and only later you figure out that people were really depending on C. Then you implement C, but D&E were really important as well. And before you know it, you're back to where you were before the rewrite: an organically grown codebase that solves A, B, C, D as well as E. The only difference with the original codebase is that it does A&B more efficiently, but C,D,E are bolted on. The original codebase had different biases (maybe C&E).
If you're going for pedantry, make sure you do it right.
In this context, TLA = Three-Letter Agency
But if those hacks should be elsewhere in an abstraction layer, that's a case for refactoring, not a rewrite. Though I typically find the first step in refactoring is to modularize everything (if it's not already). Then each piece can be refactored (or even completely rewritten if needs be) as needed.
Not that there aren't times for rewrites but backtracking to the beginning is a fairly drastic action.
I think the problem is that there's a thin line between where people call it a refactor and where you call it a rewrite. I don't think anyone actually does a literal complete rewrite where they replace every single line of code by manually retyping it out. If a refactor could be classed as modularising everything, and then rewriting each module, then that to me for all intents and purposes is a rewrite anyway - in that case I'd class the terms as interchangeable anyway.
I don't necessarily believe to be called a rewrite that every bit of code has to be rewritten by hand. I think it's sufficient that the vast majority of the codebase be rewritten for it to be termed a rewrite. If I ever was to call for something to be completely rewritten with nothing carried over I'd probably refer to it as a "full rewrite", "complete rewrite", or an "absolute rewrite".
I find backtracking to the beginning to sometimes be a useful tool for managing a major refactoring (what I'd call a rewrite), sometimes if it's the base of the application that's rotten - i.e. lacking an OS specific abstraction layer for something like, say, drawing such that there are OS specific hacks littered over completely unrelated things then I might just start a new project, build that abstraction layer and then bring the rest of the code over switching it to use that new abstraction layer so that drawing calls are drawing calls, not drawing calls with random OS specific instructions as a result of hacks in them. This is what I'd typically call a rewrite, even if large parts of the application are being brought across, but I suppose you might equally just call it a major refactoring operation if any existing code at all is carried across.
So I suppose it really depends on where you draw the line if anything. I guess you may be able to corner it to the point of saying whether you need a refactor or a fresh project depends on what part of the applications needs to be replaced - if it's something fundamental like the underlying calls to be switched from being OS specific into a nice OS neutral abstraction layer that has OS specific concrete implementations per OS to keep all the OS specific stuff separate then I'd argue that that's going to be too low down in the application to refactor in a reasonable manner. If however your drawing calls are just messy and the interfaces are cluttered with unnecessary parameters and make no sense then of course a refactor is sufficient. In other words, the further away you are abstracted from the low level guts of the application the easier it is to refactor, but if the guts themselves are fucked then it will often make sense to rewrite them from scratch and take the higher level stuff across. In this respect I would imagine it depends on what you're doing too - if your job is porting software to different operating systems then I'd imagine starting from a fresh base is a far more common thing than if you're just maintaining mature business systems that are never going to move from the platform they're already on for example.
The other place I've seen prominent rewrites is in web applications, I've seen any number of PHP applications that started to need things like proper threading to support better scalability and flexibility be rewritten in things like C#/ASP.NET or Java/Spring or similar. When you're changing stack like that the rewrite is the only option, and frankly switching from interpreted to compiled languages tends to result in better code quality anyway because whole classes of errors are caught and fixed at compile time that can trivially go unnoticed in interpreted languages like PHP so concerns about throwing out years of existing knowledge tend to be outweighed by the inherent better code quality and performance you get from JIT'd languages in that sort of circumstance anyway.
But I do agree, there's a time and a place. It's certainly not something that you should be doing too often.