TrueCrypt Cryptanalysis To Include Crowdsourcing Aspect

← Back to Stories (view on slashdot.org)

TrueCrypt Cryptanalysis To Include Crowdsourcing Aspect

Posted by samzenpus on Monday June 2, 2014 @08:50AM from the many-eyes dept.

msm1267 (2804139) writes "A cryptanalysis of TrueCrypt will proceed as planned, said organizers of the Open Crypto Audit Project who announced the technical leads of the second phase of the audit and that there will be a crowdsourcing aspect to phase two. The next phase of the audit, which will include an examination of everything including the random number generators, cipher suites, crypto protocols and more, could be wrapped up by the end of the summer."

131 comments

Min score:

Reason:

Sort:

Crowdsourcing by eedwardsjr · 2014-06-02 08:59 · Score: 1

While we're on the topic of crowdsourcing and truecrypt, how about we get someone to rebuild it open sourced?
1. Re:Crowdsourcing by cheater512 · 2014-06-02 09:04 · Score: 4, Insightful
  
  Why? It is already open sourced.
2. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 09:06 · Score: 0
  
  There's also the tc-play implementation. https://github.com/bwalex/tc-p...
3. Re:Crowdsourcing by buchner.johannes · 2014-06-02 09:09 · Score: 1
  
  I think eedwardsjr meant "make it free software" even though she/he typed "open source"
  
  --
  NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
4. Re:Crowdsourcing by buchner.johannes · 2014-06-02 09:10 · Score: 1
  
  tc-play is not a replacement, because it is Linux/BSD only. Can't have dmcrypt on Windows.
  
  --
  NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
5. Re:Crowdsourcing by NReitzel · 2014-06-02 09:29 · Score: 4, Interesting
  
  Well,
  Since Truecrypt has decided to drop their project, and the project has been opensourced from day one, I'm going to suggest this is a good time for a fork.
  It would (will) be educational to see who goes to court to stop it.
  
  --
  Don't take life too seriously; it isn't permanent.
6. Re:Crowdsourcing by westlake · 2014-06-02 09:55 · Score: 1
  
  Why? It is already open sourced.
  The TrueCrypt source is also - by most accounts - a huge ungodly mess that hasn't seen a significant update in at least the past two years.
7. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 10:15 · Score: 0
  
  Well,
  you could start the project by setting up a homepage, setup instructions for how to do the clean room implementation and start advertising at tech sites for hackers who'd like to participate in the clean room implementation of truecrypt under FOSS approved license just as soon as the analysis is done of the current source code.
  Greets
8. Re:Crowdsourcing by Razed+By+TV · 2014-06-02 10:45 · Score: 1
  
  I take it to mean crowdsourcing the attempts to verify the integrity of TrueCrypt.
  
  White said the next phase of the cryptanalysis, which will include an examination of everything including the random number generators, cipher suites, crypto protocols and more could be wrapped up by the end of the summer. Some of the work, White said, could be crowdsourced following a model used by Matasano, known as the Matasano Crypto Challenges. The now-defunct challenges were a set of more than 40 exercises demonstrating attacks on real-world crypto, exploiting weaknesses in real systems and cryptographic constructions. Those interested in participating emailed Matasano and were sent eight challenges at a time, each stage more difficult than the previous. That same format could be part of the TrueCrypt audit, White said.
9. Re:Crowdsourcing by cheater512 · 2014-06-02 10:45 · Score: 2
  
  A lot of GNU tools haven't been updated in around two decades yet no one feels like they need to be rewritten.
  I was shocked to find out the other day that the cron most Linux distributions use was last updated in 1993.
10. Re:Crowdsourcing by rahvin112 · 2014-06-02 10:49 · Score: 4, Interesting
  
  It open source but not FOSS.
  You can't fork it. The license is actually highly restrictive. The only options are a total reimplementation using the GPL or BSD license or to keep using the last version in perpetuity.
11. Re:Crowdsourcing by Kjella · 2014-06-02 11:19 · Score: 5, Informative
  
  The TrueCrypt source is also - by most accounts - a huge ungodly mess that hasn't seen a significant update in at least the past two years.
  Not seen a significant update in at least two years, check. But huge, ungodly mess? Nah, 4.45 MB uncompressed, subtract 491 kB bitmaps and icons, 902 kB user guide, 117 kB license and readme texts in several versions, 250 kb string localization, 150 kB resource, project and solution files and you're talking approximated 2.5 MB code, divided into several logical directories. I skimmed the main files and they look decently formatted and commented, on the longish side but with plenty whitespace. I think probably under 100 kLOC total, a lot of it standard cryptographic primitives, installer, GUI and so on. Once you've made sure they don't contain any funny business the actual logical core seems to be more like 20-30 kLOC, quite manageable for one man to grasp.
  
  --
  Live today, because you never know what tomorrow brings
12. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 11:35 · Score: 2
  
  Where do you get this? When I read the license it reads largely to be less restrictive than GPL 3.0. Section III of the license discusses exactly what is required to create derivative products. Basically, you have to make sure that no one will confuse it with TrueCrypt, you have to make the source available, and you can't change the license.
  The only problem I can see with it from the perspective of the people around here is that it wasn't spawned by Stallman.
13. Re:Crowdsourcing by vux984 · 2014-06-02 11:41 · Score: 3, Insightful
  
  You can't fork it.
  Are you sure.
  The license is actually highly restrictive.
  Insofar as lawyers don't like the wording as its a bit ambiguous on some fine details; but its not as restrictive you seem to think.
  Moreover, for the license to actually be a problem someone would have to come forward, establish they actually have copyright standing, and then sue you over making a fork.
  So what realistically what are the risks? That some anonymous devs who shutdown the project and have advocated everyone switch to alternative systems is going to come out of the woodwork to sue you for copyright infringment and 'damages' despite your best efforts to follow their license which DOES actually allow for forking, and for which you wouldn't be charging for copies. So there are no profits to sue for then there is the acute impossibility of you 'damaging' their interests given they discontinued the original project and burned it to the ground.
  I honestly don't understand the fear. I mean sure there is a risk there, but if you incorporate a nonprofit, continue to give it away for free, and retain the terms of the license; the risk small.
  Even if the authors did come out of the woodwork, and sue you, so what? So your non-profit shuts down - worst case. More likely by far to just walk away with little more than a cease and desist and/or a small fine, and that's assuming the court even finds against you (which given the ambiguity of the license, and your attempt to adhere to it as best as possible) isn't all that likely in the first place.
  Yet, the lawyers say its 'highly restrictive' and 'dangerous' to anyone who goes near -- same lawyers who approved the non-compete clauses that now have silicon valley under a class action? Where was their sage advice about risk then?
14. Re:Crowdsourcing by epyT-R · 2014-06-02 12:01 · Score: 1
  
  The law doesn't define reality. It's unlikely they will come forward to sue, so the license is just a letter telling us how angry they will be.
15. Re:Crowdsourcing by epyT-R · 2014-06-02 12:04 · Score: 1
  
  Just because something hasn't been updated doesn't automatically mean it's broken. Everyone's hopped on to this nonsensical upgrade treadmill. Software doesn't 'wear out.' If it's not buggy, it will stay buggy. If it's working, it will stay working.
  As far as supported vs unsupported software goes, you should be assuming your system can be compromised and planning accordingly anyway, whether you get updates or not.
16. Re:Crowdsourcing by epyT-R · 2014-06-02 12:07 · Score: 1
  
  errr... "If it's not buggy, it will stay not buggy." sorry.. Obviously, if software around it changes, bugs can crop up, but technically that's not a failure of the existing software.
17. Re:Crowdsourcing by epyT-R · 2014-06-02 12:09 · Score: 1
  
  Yeah. it seems reasonably well done, compared with todays 50MB 'utilities' and their huge runtimes and crazy dependencies.
18. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 13:30 · Score: 0
  
  Well, it does wear out in the sense the operating systems change and after some time your software needs some arcane incantations to run on a normal computer.
19. Re:Crowdsourcing by WaywardGeek · 2014-06-02 14:23 · Score: 4, Informative
  
  It's actually just a bit over 110 kLOC, but you were close. The crypto code is mostly very good. The GUI code must have been written by someone else, because it totally sucks, IMO. I was just porting it to wxgtk3.0 today from wxgtk2.8, and of course all the crypto compiled without even a warning, other than some AES code I need to look into. The GUI was a freaking nightmare. They implemented their own string class. How stupid is that? Well, they didn't just implement a string class, but they implemented a directory string class, a filename string class, a "volume" string class, a "volume info" string class, and about a dozen other string classes, most of which don't actually have any useful functionality, and just require all kinds of casting operators. Stupid stupid stupid...
  I haven't looked at the firewall between the GUI and crypto code yet. Obviously there's a fuse driver in Linux and I would not expect it to link with the GUI code at all, but I need to check. Given that the crypto code rocks, and the GUI code sucks, it's critical that they be in separate processes. That would be needed in any case, since you can't trust all that GUI library code living in the same process as the crypto core.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
20. Re:Crowdsourcing by xeoron · 2014-06-02 14:25 · Score: 4, Informative
  
  As of last weekend, it is in the process of being forked. New community site here
21. Re:Crowdsourcing by Desler · 2014-06-02 14:51 · Score: 2
  
  Software doesn't 'wear out.' If it's not buggy, it will stay buggy. If it's working, it will stay working.
  Only true if you never upgrade any part of the system it runs on. Any upgrade to the OS or its dependencies (the dependencies of those dependencies, ad infinitum) and you risk introducing bugs.
22. Re:Crowdsourcing by Rob+the+Bold · 2014-06-02 14:52 · Score: 2
  
  I honestly don't understand the fear.
  Then put YOUR ass on the line and do what you suggest. Suggesting other people put their asses on the line for your benefit just means you're a dick.
  You seem to be taking this rather personally. Why? vux984 can't make you or me or anyone else do what they don't want to do, even if he does suggest it would be okay to do so. The "dick" accusation is a petty way to state your disagreement.
  
  --
  I am not a crackpot.
23. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 16:23 · Score: 0
  
  NSA FUD.
24. Re:Crowdsourcing by Pieroxy · 2014-06-02 17:28 · Score: 3, Insightful
  
  Who is going to stop you? The authors are anonymous so who could claim to be the copyright holder to come and stop you?
  
  --
  Write boring code, not shiny code!
25. Re:Crowdsourcing by mpe · 2014-06-02 18:35 · Score: 1
  
  The GUI was a freaking nightmare. They implemented their own string class. How stupid is that? Well, they didn't just implement a string class, but they implemented a directory string class, a filename string class, a "volume" string class, a "volume info" string class, and about a dozen other string classes, most of which don't actually have any useful functionality, and just require all kinds of casting operators.
  
  Sounds like the GUI came from a completly different project. Possibly even on a different platform from any TC uses.
26. Re:Crowdsourcing by mpe · 2014-06-02 18:43 · Score: 2
  
  A lot of GNU tools haven't been updated in around two decades yet no one feels like they need to be rewritten.
  
  If it ain't broke don't try to "fix" it.
  
  I was shocked to find out the other day that the cron most Linux distributions use was last updated in 1993.
  
  How have the requirments of cron changed in lthe last 20, even 40, years?
27. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 19:00 · Score: 1
  
  A lot of GNU tools haven't been updated in around two decades yet no one feels like they need to be rewritten.
  I was shocked to find out the other day that the cron most Linux distributions use was last updated in 1993.
  And I am shocked that people have to reinvent the wheel over and over. Not to mention to skip regression checks and bring a new and 'better' version which lacks in features. There is a time when 'simple' tools are done and just do their job. IIRC tcpwrapper is on the same boat and being dropped from some distros because it hasn't changed in years despite doing its job if you need it plain and simple.
28. Re:Crowdsourcing by cheater512 · 2014-06-02 19:13 · Score: 1
  
  Not much is broken with Truecrypt from the audit's initial results.
29. Re:Crowdsourcing by Anonymous Coward · 2014-06-02 19:47 · Score: 1
  
  It was already forked at least twice. For example Realcrypt.
30. Re:Crowdsourcing by g00ey · 2014-06-02 22:00 · Score: 1
  
  What would you say about those who claim that the deniable encryption doesn't work because the parts of an encrypted volume that hold actual data has lower entropy than the parts that hold the random data? I cannot understand that claim since, as far as I understand it, encryption algorithms such as the AES uses probabilistic encryption and should have as high entropy as random data. Usually high entropy data is associated with data that is hard to compress (especially when discussing lossy compression of video) and AES encrypted data is just as incompressible as random data.
  
  I think that one cannot yield statistically significant measures of entropy that can tell the difference between random data and encrypted data in a deniably encrypted volume. But other people say otherwise. If that is the case, it shouldn't be difficult to generate random data that matches the entropy of encrypted non-random data.
31. Re:Crowdsourcing by WaywardGeek · 2014-06-02 22:31 · Score: 3, Interesting
  
  From this security analysis there is a 64K-ish block in the header that is filled with random data in Windows, but encrypted 0's in Linux. There's no simple way to insure the Windows header is indistinguishable from true random data, but the Linux version should be OK. As for the rest of the unused portion of the volume, I haven't checked the code. If it's using a pseudo-random number generator that isn't cryptographically strong, then it may be distinguishable. However, the entropy argument seems wrong to me. If the unused portion has measurably lower entropy than true random data, then the random number generator in question must have been compromised.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
32. Re:Crowdsourcing by eedwardsjr · 2014-06-03 00:01 · Score: 1
  
  Sorry. It is hard to convey it written words but the emphasis for my sentence is on the word 'rebuild'. I would rather they rebuild it open vs closed source. Since I am implying a rewrite, it would be their prerogative.
33. Re:Crowdsourcing by Anonymous Coward · 2014-06-03 00:44 · Score: 0
  
  Maybe I'm misunderstanding, but if you're trying to hide the data, why would the Windows with the "random data header" mean there's no way to insure the Windows header is indistinguishable from true random data... yet the Linux header that's "encrypted 0's" should be OK?
  Wouldn't you want the data to look, you know... Random? And which is going to look more random? A "block in hte header that is filled with random data in Windows" or "but encrypted 0's in Linux"?
34. Re:Crowdsourcing by AmiMoJo · 2014-06-03 00:51 · Score: 1
  
  Then put YOUR ass on the line
  My ass is on the line, and I don't want a cock-up!
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
35. Re:Crowdsourcing by Ardyvee · 2014-06-03 00:56 · Score: 1
  
  You can ensure that the encrypted data looks random because you are the one encrypting it. You can't, however, ensure that the random data in windows actually looks random. The next string: "monkeys can write" can result from a random source. I mean, monkeys could, theoretically, write all of Shakespeare's works given infinite time. Random doesn't mean it looks random. Random means there is no structure/logic behind it. It can *look* like something with meaning or not.
  
  --
  I don't care if I'm wrong. I only care about everyone obtaining something from the discussion.
36. Re:Crowdsourcing by jeffmeden · 2014-06-03 04:32 · Score: 1
  
  A lot of GNU tools haven't been updated in around two decades yet no one feels like they need to be rewritten.
  If it ain't broke don't try to "fix" it.
  I was shocked to find out the other day that the cron most Linux distributions use was last updated in 1993.
  How have the requirments of cron changed in lthe last 20, even 40, years?
  Where is my microsecond scheduling, you insensitive clod?
37. Re:Crowdsourcing by jeffmeden · 2014-06-03 04:42 · Score: 1
  
  Just because something hasn't been updated doesn't automatically mean it's broken. Everyone's hopped on to this nonsensical upgrade treadmill. Software doesn't 'wear out.' If it's not buggy, it will stay buggy. If it's working, it will stay working.
  As far as supported vs unsupported software goes, you should be assuming your system can be compromised and planning accordingly anyway, whether you get updates or not.
  That's true for something like an ASCII text editor where the requirements are dead simple. However when encryption, and in particular fancy-tricks encryption like deniability are part of the requirements, you bet your ass that problems will appear out of nowhere. Humans make mistakes, and humans make software, so humans make software with mistakes. Just because it passed every practical review and test the first time around, doesn't make it future-proof. With the source code and enough time, someone will find an exploitable bug. If there is no chance that the Good Guys will find it first (since they apparently caught the last train to the coast) then that leaves one eventuality, that the Bad Guys will find it first, and everything that was once safely locked up will be left hanging in the breeze.
38. Re:Crowdsourcing by rahvin112 · 2014-06-03 04:58 · Score: 0
  
  Suggesting other people takes risks and put their ass on the line for your personal benefit IS being a dick. There is nothing I'm "taking it personally" about me pointing out that obvious fact. Are you socially obtuse enough that you don't recognize a dick move when it happens? Here's another dick move, sleeping with your friends wife/girlfriend. Would you defend that as well and claim someone is taking it personal when they point out it's a dick move?
39. Re:Crowdsourcing by vux984 · 2014-06-03 05:15 · Score: 2
  
  Then put YOUR ass on the line and do what you suggest. Suggesting other people put their asses on the line for your benefit just means you're a dick.
  Yeah, that's the only possible explanation for the fact that I haven't done everything in life that I think is possible, or could or should be done by someone.
  No worst case is that because your infringement is willful they go after your personal assets.
  Infringement is not willful. There is a clear good faith argument that the license was being followed.
  But prove me wrong, get out there and spend your time and money to fork code you can't legally fork and put your ass on the line that none of the developers will decide they see a payday in your infringement.
  What payday? Its a single title, not being sold for money. Actual damages to the original author are ZERO. Theoretical damages to the original author are ZERO. What does that leave?
  Statutory damages.
  That maxes out at 50k in the US that's if its proven willful.You really telling me that's a risk silicon valley tech companies can't afford?
  And that's WORST case. And the odds of that happening are astronomically small. Far far far more probable its a cease and desist and a small fine; assuming you don't settle out of court before it even gets that far.
40. Re:Crowdsourcing by Rob+the+Bold · 2014-06-03 05:38 · Score: 1
  
  Here's another dick move, sleeping with your friends wife/girlfriend. Would you defend that as well and claim someone is taking it personal when they point out it's a dick move?
  Sorry. I didn't realize you two had a history.
  
  --
  I am not a crackpot.
41. Re:Crowdsourcing by Inconexo · 2014-06-03 21:58 · Score: 1
  
  AFAIK, it is neither free software nor open source. If you cannot fork it, it's not open source, even if the source code is published.
  Open source is that which is open to read, modify, redistribute,... Not only open to read.
good by Anonymous Coward · 2014-06-02 08:59 · Score: 0

It will help whoever picks up the pieces of TrueCrypt to fix and continue the project.
1. Re:good by Anonymous Coward · 2014-06-02 09:21 · Score: 0
  
  Ain't gonna happen. Nobody has the resources to fight the NRA on this.
2. Re:good by gweihir · 2014-06-02 10:04 · Score: 1
  
  Indeed. Although that will probably have to be done in some country that is not a budding fascism.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
3. Re:good by Anonymous Coward · 2014-06-02 12:21 · Score: 0
  
  The NRA? You mean the NSA? New Soviets of Amerika?
Open Source it by buchner.johannes · 2014-06-02 09:00 · Score: 1

If TrueCrypt devs really gave up because they think it is pointless, then they should open source the code (BSD, Apache2, GPL, MIT). There is no reason not to, unless they had contributers who passed away.
So finally, was the duress canary activated or not? If it is "still there" as according to that tweet, that should mean it was not activated.
Btw, tc-play is not a solution, because it is Linux/BSD only.

--
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
1. Re:Open Source it by Anonymous Coward · 2014-06-02 09:07 · Score: 0
  
  The issue is that it wasn't really open source in the first place, and contains code that some parties alleged was stolen.
2. Re:Open Source it by Anonymous Coward · 2014-06-02 09:08 · Score: 0
  
  If the audit comes out fine, they may well try to.
  The problem is those people will likely get targeted if it WAS a case of NSA going after the original devs. (which looks unlikely since it seems the project just disolved because of people leaving and times changing with regards to OSes dropping support for things and such)
  The future is still up in the air really. How it comes down from it is another question. It can go so many ways.
3. Re:Open Source it by Anonymous Coward · 2014-06-02 09:14 · Score: 0
  
  Which portions? :-? Could you please link some refs? Thanks.
4. Re:Open Source it by Threni · 2014-06-02 09:31 · Score: 2
  
  > So finally, was the duress canary activated or not? If it is "still there" as according
  > to that tweet, that should mean it was not activated.
  If it was clear that it had been activated, then it would breach the NSL and the authors would be at risk of legal action. Therefore, you will not see a clear canary warrant.
  There was no info in that tweet, and even Mathew Green doesn't know what they were talking about. It was just clickbait to take you to a site with old news.
5. Re:Open Source it by Anonymous Coward · 2014-06-02 09:41 · Score: 5, Informative
  
  TrueCrypt's source code is based on the earlier tool, Encryption For The Masses (E4M) [1997] by Paul LeRoux, who abandoned it in 2000 when he joined SecurStar to make the closed-source DriveCrypt with Shaun Hollingworth (who wrote a predecessor, Scramdisk). That's why the licence looks the (horrible) way it looks; it's an update of the E4M licence.
  When the TrueCrypt Team released the first version of their fork, the project lead David Tesarik got a whole bunch of nastygrams from a manager at SecurStar who alleged Paul LeRoux had stolen E4M from them and open-sourced it without their permission: https://groups.google.com/forum/#!topic/alt.security.scramdisk/HYa8Wb_4acs
  Which was complete bullshit, of course, as E4M had been opened years before SecurStar existed and they themselves published it on their website under the E4M licence, so nothing actually came of it - except 9x support was removed because it used Shaun's 'Scramdisk' driver, and he hadn't given permission to distribute with E4M if the name was changed, hence 1.0a.
  Wouldn't be surprised if there was a Slashdot article about it. Peter Gutmann suggested it'd be right up /.'s alley. :) /akr
6. Re:Open Source it by MightyMartian · 2014-06-02 09:53 · Score: 1
  
  You can't take a leak in the technology world any more without someone trying to claim IP ownership of your urethra.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
7. Re:Open Source it by gweihir · 2014-06-02 10:07 · Score: 1
  
  It looks more and more like a not-too pretty negative canary. Like a website self-defacement automatically triggered is a number of people fail to do some things regularly. Really open-sourcing things needs work. The ridiculous travesty of the original website can be put up automatically.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
8. Re:Open Source it by gweihir · 2014-06-02 10:08 · Score: 1
  
  I think by now things are clear enough: The alternatives immediately after it happened were defacement or canary. As a defacement would have been cleaned up by now, it has to be canary. And yes, the developers would go to prison if they made that really clear, so a minimum of independent intelligence is required to see it.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
9. Re: Open Source it by epyT-R · 2014-06-02 12:24 · Score: 1
  
  How do you know it is bullshit? Are you speaking from fact or are you also speculating? Isn't it safer to assume government compromise in this situation?
10. Re:Open Source it by muridae · 2014-06-02 12:35 · Score: 1
  
  If it is a NSA/NSL canary, then the devs are restricted in what they can say about why they are abandoning the project. The logical choice, and the easiest lie to remember, is that "we are just tired of developing it."
  Which, unfortunately, is also the same exact thing they would say if they were just giving up on developing it. So the only real clues are the content of the current web page, and the changes made to the new 7.2 TrueCrypt. That they suggest using BitLocker without a TPM chip (I never thought I'd be suggesting the use of a pre-made TPM chip; honest) and that the solution involves upgrading to the pro version of windows . . . it doesn't pass the smell test. Serious crypto guys wouldn't suggest those tools when drunk, much less just because they are quitting.
  As for "we don't know who the people who 'verified' the canary are" . . . that's another part of those nasty NSLs. If the people who knew the canary were close enough to the project, they would be subject to the NSL terms and silenced. It makes sense that a good canary is one that only one or two people un-connected to the project know about. If, for example, the devs put a big dead yellow bird on their webpage, it would clue us all in, but it would also violate most of the "shut up or else" clauses of a NSL. So, the devs may have prearranged a few phrases, told one of X to Y different people who knew each other but had little to connect with the devs, and then hoped they could get some Z phrases (Z
  Assumption made about NSA and USA NSLs. Could be the same thing from other governments, or the threat of having their family killed by mobsters. The cause doesn't matter as much as the result, which is that 7.2 looks very fishy and we all avoid it.
11. Re: Open Source it by fnj · 2014-06-02 13:14 · Score: 1
  
  Don;t bother arguing substance with the AC moron. He is absolutely clueless.
12. Re:Open Source it by Anonymous Coward · 2014-06-02 17:47 · Score: 0
  
  If TrueCrypt devs really gave up because they think it is pointless, then they should open source the code (BSD, Apache2, GPL, MIT). There is no reason not to, unless they had contributers who passed away.
  There is another reason. TrueCrypt is already open source.
  It uses the TrueCrypt license.
  It is hard to change something into a state it already is in.
13. Re: Open Source it by gweihir · 2014-06-03 01:58 · Score: 1
  
  Somebody is in denial.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
14. Re:Open Source it by gweihir · 2014-06-03 02:04 · Score: 1
  
  That they suggest using BitLocker without a TPM chip (I never thought I'd be suggesting the use of a pre-made TPM chip; honest) and that the solution involves upgrading to the pro version of windows . . . it doesn't pass the smell test. Serious crypto guys wouldn't suggest those tools when drunk, much less just because they are quitting.
  Indeed. Or the fact that for OS X, they give "encryption: none" as selection. Or the slap-dash look. (My guess is the look is specifically to suggest a defacement in order to get maximum press exposure and make the message even clearer when a few days later it becomes clear it is not a defacement.)
  All quite clear, but the reasoning required seems to exceed what effective intelligence some people have.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
15. Re: Open Source it by gweihir · 2014-06-03 02:07 · Score: 1
  
  Indeed. Probably knows it too, some people take "AC" as an excuse to not check their facts at all.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
How about the build tools and the OS? by T.E.D. · 2014-06-02 09:16 · Score: 1

According to Ken Thompson, if you don't also analyze all the tools involved in the software build and load process at the machine code level, you still can't really trust the code. That means compilers, linkers, loaders, etc. Someone who knows what they are doing, and has enough motiviation to go through the effort, could insert code into a compiler that does whatever they want when your code is built with it, and hides itself at the source level.
These days CPUs are sophisticated enough that you probably would need to check them (and any microcode layer they may have) as well.
1. Re:How about the build tools and the OS? by jcochran · 2014-06-02 09:22 · Score: 3, Insightful
  
  You just might want to look 'Diverse Double-Compiling' as a method of countering the attack described by Ken Thompson in 'Reflections on Trusting Trust'. A paper on DDC is at http://www.acsa-admin.org/2005...
2. Re:How about the build tools and the OS? by mSparks43 · 2014-06-02 09:33 · Score: 1
  
  Actually, this isn't true.
  Because encrypted container that contains "weak" encryption wont be able to be decrypted by a build that doesn't have the same weakness.
  It's also the reason bitlocker isn't a replacement - I cant use bitlocker on linux, I use truecrypt containers to store stuff in the cloud, and access from a variety of machines.
  what it really needs is some tidying up, forget about whole disk encryption, and concentrate on making sure the install is safe from tampering.
3. Re:How about the build tools and the OS? by T.E.D. · 2014-06-02 09:36 · Score: 1
  Interesting idea. But I see two problems there:
  
  It doesn't do anything about the same issue with linkers, the OS's executable loader, your CPU, etc. I suppose you could also try to apply the same concept to then, but them you get to my next issue...
  If your problem is that you don't know if you can trust your compilers, a solution that starts with "first, go get a trusted compiler" is kind of an infinitely recursive solution.
4. Re:How about the build tools and the OS? by Anonymous Coward · 2014-06-02 09:51 · Score: 0
  
  Because encrypted container that contains "weak" encryption wont be able to be decrypted by a build that doesn't have the same weakness.
  That depends very much on the weakness. If the weakness is in the psudorandom number generator or is it is discovered there are weak keys that need to be avoided, it's possible for a older weak version to interact perfectly well with a newer strong version.
5. Re:How about the build tools and the OS? by jcochran · 2014-06-02 10:01 · Score: 2
  
  It does address the issues you mentioned. As for the tool chain (compiler, linker, loader, etc), that is addressed by making them diverse. The term 'compile' means the entire chain from source to binary which includes the entire tool chain. As for the CPU issue, there's nothing in the source that mandates that you must create a binary for the same CPU as you're executing on. So do DDC on multiple CPU families (Intel, ARM, PPC, etc) and compare the final results. And the beauty of DDC is you can do it even if the tools you're using have been compromised. The only requirement is that the tools not be compromised in EXACTLY the same way. Any difference in the actual behavior of the tool chain will result in a difference in the output to be compared. If you're extremely paranoid, there's nothing preventing you from executing the tool chain inside an emulator to bypass any issues you might have with microcode.
6. Re:How about the build tools and the OS? by gweihir · 2014-06-02 10:12 · Score: 2
  
  He is wrong and it was only ever a strong hypothesis on his part. Newer research shows that it is a lot easier to build in a way that excludes compiler backdoors: http://www.dwheeler.com/trusti...
  The idea is fascinating. It basically says if you have a really crappy and simple compiler that can compile your code and that you can trust, you can propagate that trust on a really good and complicated compiler. Writing a crappy and simple C compiler can be done in a few weeks.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
7. Re:How about the build tools and the OS? by gweihir · 2014-06-02 10:15 · Score: 1
  
  The OS, loader and CPU are minor issues, as they do not have the power to analyze your code. And getting a compiler you trust is simple: Write it yourself. Unless the compiler you use to do that was specifically designed to attack your compiler, it will be ineffective.
  Incidentally, the risk of this attack actually happening in practice is very low, as it is exceedingly difficult to implement and as soon as it has bugs the risk of discovery is pretty big.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
8. Re:How about the build tools and the OS? by gweihir · 2014-06-02 10:16 · Score: 1
  
  You cannot make encryption weak by compiling it badly. You can cause leaks of key material, but only at times the material is actually in use and for disk encryption that attack is irrelevant.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
9. Re:How about the build tools and the OS? by sexconker · 2014-06-02 10:48 · Score: 1
  
  He is wrong and it was only ever a strong hypothesis on his part. Newer research shows that it is a lot easier to build in a way that excludes compiler backdoors: http://www.dwheeler.com/trusti...
  The idea is fascinating. It basically says if you have a really crappy and simple compiler that can compile your code and that you can trust, you can propagate that trust on a really good and complicated compiler. Writing a crappy and simple C compiler can be done in a few weeks.
  Yeah but how are you going to compile your compiler?
10. Re:How about the build tools and the OS? by idontgno · 2014-06-02 10:58 · Score: 2
  
  Hand-compile, then hand-assemble, and finally poke opcodes into RAM with front-panel switches.
  No, I'm not kidding.
  
  --
  Welcome to the Panopticon. Used to be a prison, now it's your home.
11. Re:How about the build tools and the OS? by lgw · 2014-06-02 11:06 · Score: 1
  
  Sounds interesting, but the abstract for that DDC paper is gibberish.
  
  In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compilerâ(TM)s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.
  
  It this saying "write your own compiler, then use it to compile GCC, then use that to compile GCC"? I.e., the normal process for bootstrapping GCC to a new architecture?
  Meh, better be running those compiles on a completely trusted OS (which you built how?), on a completely trusted processor (the masks were checked how?). I guess it's a good idea, since the more diverse you go on platforms, the more likely you'd be to find one that's trustworthy. Sadly, it could be defeated by an attacker with unbounded funding, reach, and decades of work to subvert every platform out there.
  This is the real problem with the evil of the NSA. You have to be able to trust something to have a beachhead to build on. But the NSA destroyed trust in everything.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
12. Re:How about the build tools and the OS? by sexconker · 2014-06-02 11:34 · Score: 1
  
  The person I replied to said it oculd be done in a few weeks. What you suggest takes months to years.
  And front-panel switches for RAM? WTF are you even talking about? Why would you even need to do that if you've already done everything by hand?
13. Re:How about the build tools and the OS? by muridae · 2014-06-02 13:23 · Score: 1
  
  And for compiling something like a basic C compiler, one could feasibly write their own using ASM from a base of something like CC500 (a 600ish line C compiler). Use said custom compiler to build something like PintOS (full code review possible by one person, I had to do so in collegiate OS courses) on a micro that is running nothing but your compiler from a RS232 port that you are monitoring with a logic analyzer (to watch out for stray data from the 'host' computer at this point). This gets you up to OS and compiler on your chip and board of choice, though you may need a bootloader. From there, you could compile the rest of a known tool chain, like GCC and all it's accompanying tools; if you've reviewed them satisfactorily.
  As for trusting your hardware: good luck, you'll need it. Even if you can get a copy of the lithos used in producing your chip, you will have just a statistical analysis of the chance of a spy in your chip. Since you can't just decap and dissolve the layers to make sure. Perhaps with the lithos in hand you could get custom made chips, but that's not going to be any 'big iron' like an x86-64. So you've shifted the needed trust down to just the silicon (and microcode if needed) that are comparatively harder for an individual to make on their own. I suppose you could mimic the CPU on an FPGA or PLC, but you are back to "trusting trust" that the compiler didn't recognize something and stuff it in the binary.
  It still amuses me that the shift from analog devices to digital shifted where the specialization was required so drastically. A 555 could be built from a handful of discrete components (resistors were just long lengths of wire, capacitors were just two plates with a gap, and diodes were whiskers; transistors were the exception), but programming analog devices was considered a black magic art. Now, with IDEs and reference books most people can write some code if they sit down and follow a book (like building a crystal radio from a kit back in the "before my time" days) but building the hardware at the most basic level (logic gates on silicon) is magic beyond all but a few.
14. Re:How about the build tools and the OS? by muridae · 2014-06-02 13:29 · Score: 1
  
  Why not? Assume, for discussion, a malicious compiler. It looks for common code used in encryption and changes parts of the code (see Reflections on Trusting Trust). Identifying the keys should not be that hard with known algorithms, so go for that. Then just replace all keys with 0xDEADBEEF or another known pattern of bits. Viola, encrypted data that can be opened only with code compiled via the corrupt compiler, or by the attacker who knows what bit pattern was used.
  This would also be why verifying that TrueCrypt 7.1 could be compiled with a known compiler and certain settings to get a binary with the same fingerprint as the one distributed. The binary distribution could have been corrupted intentionally or by a malicious compiler.
15. Re:How about the build tools and the OS? by mSparks43 · 2014-06-02 13:48 · Score: 1
  
  "But only at times the material is actually in use". .....
  Or when such key material is encrypted into the file with a master key.....
16. Re:How about the build tools and the OS? by Anonymous Coward · 2014-06-02 15:04 · Score: 0
  
  How would hand compiling and assembling take years?
17. Re:How about the build tools and the OS? by Anonymous Coward · 2014-06-02 17:56 · Score: 0
  
  As for trusting your hardware: good luck, you'll need it.
  Or you can build your own CPU using a 74181 and some 74xx-logic. It is what it was made for and really not that hard.
  Theoretically all memories can be compromised and contain a controller that attempts code injection. In that case you need to do a memory dump to see that the memory outputs the compiler binary in the right state.
18. Re:How about the build tools and the OS? by T.E.D. · 2014-06-03 01:43 · Score: 1
  
  The OS, loader and CPU are minor issues, as they do not have the power to analyze your code.
  You mean are not supposed to have. You are being awfully trusting here of un-analyzed code.
  
  And getting a compiler you trust is simple: Write it yourself.
  In what universe is that simple? Writing a functional C compiler takes on the order of man-decades. C++ is a factor of 10 longer. For a large team, you'd have to somehow be able to trust your entire team (and your network security!) for that entire time. For a single person, it would be a lifetime's work (or more).
19. Re:How about the build tools and the OS? by T.E.D. · 2014-06-03 01:57 · Score: 1
  
  Presumably the "crappy and simple" compiler is written directly in machine language. That's the only way the GP's thesis works out.
  However, I highly doubt that you can write even a crappy and simple C compiler in machine language "in a few weeks". Unless "few" is measured in the hundreds.
  (FWIW, I don't claim to be the world's foremost expert in this stuff, but I did my master's thesis on compiler construction, so I do at least know a little bit on this topic).
20. Re:How about the build tools and the OS? by gweihir · 2014-06-03 02:08 · Score: 1
  
  With itself. Duh.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
21. Re:How about the build tools and the OS? by gweihir · 2014-06-03 02:10 · Score: 1
  
  It is not gibberish, the thing is just complicated. Look into the thesis to really understand what is going on. As he also has a formal proof that this works, the level of confidence I have in it is very high.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
22. Re:How about the build tools and the OS? by gweihir · 2014-06-03 02:12 · Score: 1
  
  Analyzing code is a high-effort, big-database and lots and lots of cycle task.
  As to the effort of writing a simple, crappy C compiler: If you need more than a month, then you are just not a good programmer.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
23. Re:How about the build tools and the OS? by gweihir · 2014-06-03 02:14 · Score: 1
  
  Simple: The result of the encryption has to be bit-identical for things to work. Attacks on crypto by corrupting the cipher are not practical for widely distributed software. And even if you corrupt the cipher, it has to be bijective in order to work at all. Not easy.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
24. Re:How about the build tools and the OS? by gweihir · 2014-06-03 02:15 · Score: 1
  
  At that time, it is obviously "in use".
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
25. Re:How about the build tools and the OS? by idontgno · 2014-06-03 02:21 · Score: 1
  
  "compile by hand" and "assemble by hand" means "write out the results on paper".
  After that, you have to get the machine code into core. That's what the front panel is for.
  Is this somehow new to you? Are you really that young, and that unfamiliar with computing history?
  Of course, if you have a functional operating system you think you can trust, you can poke the machine code into a file using a binary editor (that you think you can trust), and then execute that file as the compiler.
  Read about bootstrapping. It's a real thing, or at least was. Cross-compiling has kind of eliminated the need, except in the rather exotic use case that you don't trust the compiler (à la Ken Thompson).
  
  --
  Welcome to the Panopticon. Used to be a prison, now it's your home.
26. Re:How about the build tools and the OS? by T.E.D. · 2014-06-03 04:09 · Score: 1
  
  "Gibberish" is a bit much. But the GP is exactly right on all other counts. What is being proposed is a ridiculous amount of work, relies on perfect security thereafter, and only addresses a single vector of many that were mentioned in Thompson's talk. It reads a lot more like a "go back to sleep, all is well" paper than an actual practical solution. If I'm wrong, then surely people are doing what he suggested right now. So who are they?
27. Re:How about the build tools and the OS? by lgw · 2014-06-03 05:31 · Score: 1
  
  Formal proofs of correctness mean nothing when it comes to real-world code, even before accounting for malicious project members.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
28. Re:How about the build tools and the OS? by mSparks43 · 2014-06-03 06:49 · Score: 1
  
  I'm not sure you understood me correctly.
  You create an encrypted container using the password "superstrongnoonecanaccesspassword".
  then your container has put into it "thiscontainerspassword="superstrongnoonecanaccesspassword""
  encrypted with
  AllTheFedsHaveThisDecryptKey.
  Like Bitlocker.
29. Re:How about the build tools and the OS? by gweihir · 2014-06-03 12:24 · Score: 1
  
  Ah, I see. That is not how it works in any sane design. In a sane design, the password is unknown to the container and protects a master key that has been generated in a cryptographically strong fashion. In a sane design, there also is no space where you could put a copy of the master key or password "protected" in a fashion you describe.
  Of course, bitLocker may just do that, exactly as you describe, and not be a sane design. One more reason to insist that crypto-software is open, the metadata and design is fully documented, and the users can compile it for themselves. Otherwise what you describe is indeed extremely easy to do.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
30. Re:How about the build tools and the OS? by gweihir · 2014-06-03 12:25 · Score: 1
  
  This is a PhD theses. Have a look at it. It is actually feasible. Of course it is a lot of work initially, but just once.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
31. Re:How about the build tools and the OS? by gweihir · 2014-06-03 12:27 · Score: 1
  
  Have a look at this one. It is a bit different. We are not talking about code verification here. This is a proof that the approach works, including a trace from a proof-checker and all steps. Can be verified by anybody competent in maybe a week or so.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
32. Re:How about the build tools and the OS? by mSparks43 · 2014-06-03 12:41 · Score: 1
  
  It's perfectly sane if you're the NSA or affiliated with them, not so sane if you are using products they've tampered with.
  The point with the compile chain/tool, is the compiler can be modified to build in exactly that kind of feature (there's an example from bell I think that did something very similar, since C compilers are compiled by previous version of themselves).
  Its far more ubiquitious than it should be, for example these guys
  http://www.phoenixintelligence...
  Have a ton of hardware installed at microsoft, analysing everything that goes through microsofts servers.
  It wouldn't be so much of a problem, if they hadn't re-engineered themselves into industrial espionage.
Truecrypt fork by Anonymous Coward · 2014-06-02 09:33 · Score: 2, Informative

The beauty of opensource is good projects never die.
http://truecrypt.ch/
1. Re:Truecrypt fork by Anonymous Coward · 2014-06-02 11:09 · Score: 0
  
  switzerland, not chinese. .ch vs .cn
2. Re:Truecrypt fork by Rhymoid · 2014-06-02 11:18 · Score: 5, Informative
  .cn: China
  .ch: Switzerland (Confoederatio Helvetica; Latin, because the four languages used in Schweiz/Suisse/Svizzera/Svizra don't otherwise agree on the appropriate abbreviation)
3. Re:Truecrypt fork by scottbomb · 2014-06-07 09:53 · Score: 1
  
  Doh! I stand corrected.
4. Re:Truecrypt fork by scottbomb · 2014-06-07 09:54 · Score: 1
  
  Very interesting, thanks. I was wondering where the ch came from.
Will they distrubute the reviewed source by Anonymous Coward · 2014-06-02 09:36 · Score: 1

Will they digitally sign a copy of the source they reviewed?
What encryption will be used for the signature? Will anyone trust it?
??????
Pointless by nurb432 · 2014-06-02 09:45 · Score: 0

Even if they 'approve' the code, who will trust it? I know i wont. The ship has sailed, use that money for something useful.

--
---- Booth was a patriot ----
1. Re:Pointless by Anonymous Coward · 2014-06-02 10:00 · Score: 2
  
  The program (at 7.1a) is still completely useful for an individual or business to scramble personal/business records, in case the computer is lost or stolen, or the overnight cleaning lady is snoopy, etc.
2. Re:Pointless by dave562 · 2014-06-02 10:01 · Score: 5, Interesting
  
  This is what we are seeing in the field. A number of large financial institutions and government organizations who we deal with on a regular basis have already told us that they are no longer going to use TrueCrypt.
  Most of them are moving towards SecureZip from PKware because it supports AES-256 and is FIPS 140 compliant. Others seem to be okay with 7Zip's "encrypted zip" feature (also AES-256). Others are looking at random packages that I have never heard of before last week, like BestCrypt. Of course there are others who want to go with Symantec's PGP.
  This has proven to be a major pain the ass. For all of its warts, TrueCrypt was the de facto standard for secure data exchange. Now we are seeing a Balkanization of encryption software, and organizations are moving in different directions.
  Personally I think that TrueCrypt is good enough for transferring data on an external USB drive and protecting it against accidental or intentional theft (by anyone other than the NSA). However it is going to be impossible to convince others of that, and I cannot state it with 100% certainty so I am not even trying to have that conversation within the business context.
  As long as Client X is demanding encryption tool Z, that is fine. We will use that tool and let them shoulder the risk. After all, they are telling us what to use, not the other way around.
3. Re:Pointless by Anonymous Coward · 2014-06-02 10:19 · Score: 3, Insightful
  
  Why did you trust it in the first place? You trust unaudited code because the author says its fine but won't trust audited code that the author abandoned?
4. Re:Pointless by nurb432 · 2014-06-02 10:32 · Score: 0
  
  I ( and many others ) have to disagree, its not useful any longer, and a security risk.
  
  --
  ---- Booth was a patriot ----
5. Re:Pointless by nurb432 · 2014-06-02 10:34 · Score: 1
  
  Who said my organization didn't already audit it? And there is more going on here than a simple project abandonment.
  
  --
  ---- Booth was a patriot ----
6. Re: Pointless by Anonymous Coward · 2014-06-02 11:05 · Score: 0
  
  Care to prove that statement? Since, you know, if you can't it's not fucking obvious.
  You people are worse than CNN. "Oh look, a story with no information and no leads, let's speculate about it as if we're informed experts!" You know fuck all about what influenced their decision to ditch the project. If you're going to claim you do, demonstrate the evidence.
  You think you're not full of shit, prove me wrong.
7. Re:Pointless by Anonymous Coward · 2014-06-02 11:48 · Score: 0
  
  Well you certainly didn't say they did, nor who your organization is nor what evidence you have of any audit or its findings. What if I said my organization audited the NSA and found out it was run by lizard people?
  Captcha: audited, lol
8. Re:Pointless by epyT-R · 2014-06-02 12:33 · Score: 3, Insightful
  
  Why would these organizations switch to unknowns? If they trusted truecrypt up to this point, why not continue to trust? These closed source applications could be backdoored and there's no way of really finding out. If you think source auditing is difficult, try auditing a binary.
  It was never possible to trust truecrypt or anything else with 100% certainty.
9. Re:Pointless by Anonymous Coward · 2014-06-02 12:34 · Score: 0
  
  On what basis?
10. Re:Pointless by muridae · 2014-06-02 12:37 · Score: 3, Interesting
  
  Would you care to elaborate? The audit is by a third party, their trust could be verified; perhaps easier than trusting the unaudited TrueCrypt. Why is an audited 7.1 a security risk?
11. Re:Pointless by muridae · 2014-06-02 12:45 · Score: 1
  
  So what if there is? Assuming that your organization did audit 7.1, and found no problem, what makes it a risk now? Sure, you wouldn't want to migrate to 7.2 in a years time, and any fork from 7.1 would require a new audit; but I would hope that if you put that much effort into it that you would audit 7.2 internally or any further fork version as well, which would leave you with either a 'this is clean' or 'this is fishy' answer.
  I don't doubt that many large organizations are looking at directions to migrate, since the 7.1 public audit won't be done for a while and the security of even the old version is thrown into question (and a cursory audit by even crypto pros can miss things) so the lack of trust seems obvious. I just don't understand the sudden increase in lack of trust when compared to "hey, this code by two guys we don't know provides some pretty heavy encryption that takes a Ph.D. in maths to understand and check." I do, however, understand the need of a large corporation to plan future migration, and that knowing what you'll be using next year or in 5 years is important, and the audit of 7.1 might not be finished or may turn up flaws by then. It's the short term trust change that I don't get.
12. Re:Pointless by Desler · 2014-06-02 15:12 · Score: 1
  
  Where's the audit and the methodology, then?
13. Re:Pointless by Anonymous Coward · 2014-06-02 17:19 · Score: 0
  
  I am quite happy with ROT-13 and some home-brewed XOR code. Cannot be broken, guaranteed. As evidence I offer that The Agency has not been knocking at my door to try and install a backdoor into the code.
14. Re:Pointless by Anonymous Coward · 2014-06-02 22:26 · Score: 0
  
  Why would these organizations switch to unknowns? If they trusted truecrypt up to this point, why not continue to trust?
  Because the official TC web page states in red text that the software isn't secure.
  Why would you continue using security software which the vendor itself claims to be insecure?
  Let me put it this way: after learning about heartbleed, would you continue using the affected code, or would you upgrade as soon as possible and avoid using the old code meanwhile?
  According to your logic, you trusted it yesterday, so you should continue doing so forever.
  I get the point about switching to some random software package though. It's a tough spot to be in, but TC is now dead as a secure exchange format, at least until events are cleared up.
  Many people are working on the assumption that the TC devs simply wanted to give up, or were Lavabit'd and therefore the previous version is perfectly fine to continue using.
  However, possibility is that they found a major vulnerability affecting TC containers which goes back years.
  In that light, their actions make more sense:
  - since the software is open source they can't fix the problem without exposing the vulnerability and essentially cracking open all existing TC volumes
  - closing the source wouldn't work either since no one would trust it (people barely trusted TC as it was), and it also risks exposing the vulnerability by studying the binary
  The only real option seems to be to burn the project down and warn people that it isn't secure to continue using it, and enforcing it by publishing an update which only allows reading from containers for data migration purposes.
What to use... by Anonymous Coward · 2014-06-02 11:40 · Score: 0

So I had been kind of looking forward to the next version of TrueCrypt as the devs were claiming Win8 / Linux dual boot support; at the moment my Win8 partition is unencrypted and I'm using an encrypted home directory on the Linux partition. Encrypted home seems to be considerably slower than full disk encryption on Linux, and I'd rather have a single piece of free software that can fully encrypt the whole disk including both OSes. Does such a beast exist?
1. Re:What to use... by epyT-R · 2014-06-02 12:35 · Score: 1
  
  you wouldn't want truecrypt for that anyway as the linux truecrypt runs through FUSE, slowing things considerably.
2. Re: What to use... by Anonymous Coward · 2014-06-02 21:29 · Score: 0
  
  No way, it uses dm-crypt. Please inform yourself before posting bull**it
Switches... by Grog6 · 2014-06-02 12:09 · Score: 1

I have loaded a test program, 47,683 different opcodes, into a pdp11 with no terminal; just to run a test. :shudder:

--
Truth isn't Truth - Guliani
Re: BestCrypt is not "random" by Anonymous Coward · 2014-06-02 14:33 · Score: 3, Interesting

Best Crypt is made by Jetico, a finnish crypto software/hardware company that's been around since the early 90's. Their OTFE is top notch and the linux version is full featured with GUI. Both binary and source code packages for linux can be downloaded for free though they don't advertise it. In fact, Best Crypt was used in the Bill Clinton white house. Check them out: www.jetico.com
Technical leads by ThatsNotPudding · 2014-06-02 23:43 · Score: 1

Is there a method for individuals to legally canary themselves if they get NSL-ed (which wouldn't surprise me in the least for this audit)?
1. Re:Technical leads by feufeu · 2014-06-13 19:21 · Score: 1
  
  What about moving out of the US of A ? I hear there are other countries with running water now...
New TrueCrypt by Anonymous Coward · 2014-06-03 11:43 · Score: 0

Developers could take the example of TrueCrypt, but rewrite it from the ground up to make it secure from now up to year 2140... like using Threefish with 1024 bits, key and block size, some good hash tweaked to provide 2048 bits, some good and secure mode of operation (XTS was used in TrueCrypt... but I don't know if it's really secure), and some kind of EnScrypt (https://www.grc.com/sqrl/scrypt.htm) that is based on time, to make sure that if it takes the user for example 5 seconds, but may take decades to find the password if it's an attacker... or more if it's a really good password!
The password could be one chosen by the user, or something like a USB flash drive that identifies it self (maybe require a extra pin/ password for more protection)... because making a 157 all ASCII characters password seems unreasonable even for most paranoid person... not to talk about most of people remembering it... bellow keyboard is not really a good place to hide the note ;)
So, make it good, cross platform, and made for stay the next 100 years or more... if NIST and ECRYPT II say symmetric 256 bits should be good enough up to year >2040, sure even with quantum computing (if it becomes reality one day) should take more than 100 years to break 1024 bits symmetric cipher with all around good parameters and technology.