Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

TrueCrypt Cryptanalysis To Include Crowdsourcing Aspect

samzenpus posted about 1 month ago | from the many-eyes dept.

Security 131

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

cancel ×

131 comments

Crowdsourcing (1)

eedwardsjr (1327857) | about 1 month ago | (#47149607)

While we're on the topic of crowdsourcing and truecrypt, how about we get someone to rebuild it open sourced?

Re:Crowdsourcing (4, Insightful)

cheater512 (783349) | about 1 month ago | (#47149653)

Why? It is already open sourced.

Re:Crowdsourcing (1)

buchner.johannes (1139593) | about 1 month ago | (#47149699)

I think eedwardsjr meant "make it free software" even though she/he typed "open source"

Re:Crowdsourcing (4, Interesting)

NReitzel (77941) | about 1 month ago | (#47149857)

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.

Re:Crowdsourcing (4, Interesting)

rahvin112 (446269) | about 1 month ago | (#47150507)

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.

Re:Crowdsourcing (2)

Anonymous Coward | about 1 month ago | (#47150823)

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.

Re:Crowdsourcing (-1)

Anonymous Coward | about 1 month ago | (#47152561)

The only problem I can see with it from the perspective of the people around here is that it wasn't spawned by Stallman.

They are fewer than you think.

If you want an estimate, look at how often you see people write GNU/Linux instead of Linux. (When talking about Android if you just want to find the retarded zealots.)

Re:Crowdsourcing (3, Insightful)

vux984 (928602) | about 1 month ago | (#47150853)

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?

Re:Crowdsourcing (-1, Troll)

rahvin112 (446269) | about 1 month ago | (#47151467)

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.

So your non-profit shuts down - worst case.

No worst case is that because your infringement is willful they go after your personal assets. 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.

Re:Crowdsourcing (2)

Rob the Bold (788862) | about 1 month ago | (#47152003)

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.

Re:Crowdsourcing (4, Informative)

xeoron (639412) | about 1 month ago | (#47151833)

As of last weekend, it is in the process of being forked. New community site here [truecrypt.ch]

Re:Crowdsourcing (0)

Anonymous Coward | about 1 month ago | (#47152371)

NSA FUD.

Re:Crowdsourcing (1)

epyT-R (613989) | about 1 month ago | (#47150963)

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.

Re:Crowdsourcing (-1, Troll)

rahvin112 (446269) | about 1 month ago | (#47151503)

No, the license is a legal authority for them and their heirs to sue anyone that forks that software for around the next 120 years. If the copyright is registered they can get statutory damages for every single copy made regardless of circumstances (ie even if you give it away free).

So step up and put your ass on the line and work under the assumption that the developers nor their heirs for the next 120 years will try to capitalize on your infringement. Fork it and start coding, put yourself and all your assets on the line.

Re:Crowdsourcing (3, Insightful)

Pieroxy (222434) | about 1 month ago | (#47152531)

Who is going to stop you? The authors are anonymous so who could claim to be the copyright holder to come and stop you?

Re:Crowdsourcing (1)

Anonymous Coward | about 1 month ago | (#47152907)

It was already forked at least twice. For example Realcrypt.

Re:Crowdsourcing (1)

westlake (615356) | about 1 month ago | (#47150089)

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.

Re:Crowdsourcing (2)

cheater512 (783349) | about 1 month ago | (#47150481)

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.

Re:Crowdsourcing (2)

mpe (36238) | about 1 month ago | (#47152755)

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?

Re:Crowdsourcing (1)

cheater512 (783349) | about 1 month ago | (#47152803)

Not much is broken with Truecrypt from the audit's initial results.

Re:Crowdsourcing (1)

Anonymous Coward | about 1 month ago | (#47152781)

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.

Re:Crowdsourcing (5, Informative)

Kjella (173770) | about 1 month ago | (#47150715)

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.

Re:Crowdsourcing (1)

epyT-R (613989) | about 1 month ago | (#47151009)

Yeah. it seems reasonably well done, compared with todays 50MB 'utilities' and their huge runtimes and crazy dependencies.

Re:Crowdsourcing (4, Informative)

WaywardGeek (1480513) | about 1 month ago | (#47151819)

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.

Re:Crowdsourcing (1)

mpe (36238) | about 1 month ago | (#47152725)

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.

Re:Crowdsourcing (1)

g00ey (1494205) | about 1 month ago | (#47153227)

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 [wikipedia.org] 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.

Re:Crowdsourcing (3, Interesting)

WaywardGeek (1480513) | about 1 month ago | (#47153355)

From this security analysis [privacy-cd.org] 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.

Re:Crowdsourcing (1)

epyT-R (613989) | about 1 month ago | (#47150979)

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.

Re:Crowdsourcing (1)

epyT-R (613989) | about 1 month ago | (#47150995)

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.

Re:Crowdsourcing (0)

Anonymous Coward | about 1 month ago | (#47151559)

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.

Re:Crowdsourcing (2)

Desler (1608317) | about 1 month ago | (#47151999)

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.

Re:Crowdsourcing (1)

Razed By TV (730353) | about 1 month ago | (#47150477)

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.

Re:Crowdsourcing (1)

eedwardsjr (1327857) | about 1 month ago | (#47153753)

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.

Re:Crowdsourcing (0)

Anonymous Coward | about 1 month ago | (#47149667)

There's also the tc-play implementation. https://github.com/bwalex/tc-p... [github.com]

Re:Crowdsourcing (1)

buchner.johannes (1139593) | about 1 month ago | (#47149713)

tc-play is not a replacement, because it is Linux/BSD only. Can't have dmcrypt on Windows.

Re:Crowdsourcing (0)

Anonymous Coward | about 1 month ago | (#47150257)

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

good (0)

Anonymous Coward | about 1 month ago | (#47149609)

It will help whoever picks up the pieces of TrueCrypt to fix and continue the project.

Re:good (0)

Anonymous Coward | about 1 month ago | (#47149805)

Ain't gonna happen. Nobody has the resources to fight the NRA on this.

The NRA (1)

glrotate (300695) | about 1 month ago | (#47150149)

I can just see Charlton Heston:

Any encryption in the hands of a decent person is no threat to anybody — except bad .... hear and to heed, and especially for you, Mr. Obama: From my cold dead hands!

Re:good (0)

Anonymous Coward | about 1 month ago | (#47151091)

The NRA? You mean the NSA? New Soviets of Amerika?

Re:good (1)

gweihir (88907) | about 1 month ago | (#47150155)

Indeed. Although that will probably have to be done in some country that is not a budding fascism.

Open Source it (1)

buchner.johannes (1139593) | about 1 month ago | (#47149619)

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.

Re:Open Source it (0)

Anonymous Coward | about 1 month ago | (#47149677)

The issue is that it wasn't really open source in the first place, and contains code that some parties alleged was stolen.

Re:Open Source it (0)

Anonymous Coward | about 1 month ago | (#47149741)

Which portions? :-? Could you please link some refs? Thanks.

Re:Open Source it (5, Informative)

Anonymous Coward | about 1 month ago | (#47149967)

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

Re:Open Source it (1)

MightyMartian (840721) | about 1 month ago | (#47150075)

You can't take a leak in the technology world any more without someone trying to claim IP ownership of your urethra.

Re:Open Source it (0)

Anonymous Coward | about 1 month ago | (#47149685)

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.

Re:Open Source it (2)

Threni (635302) | about 1 month ago | (#47149881)

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

Re:Open Source it (1)

gweihir (88907) | about 1 month ago | (#47150205)

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.

Re: Open Source it (-1)

Anonymous Coward | about 1 month ago | (#47150675)

Bullshit. Complete and utter bullshit.

Sure, those might be the only options for a paranoid nutsack's tiny little mind. But if you have time in between wrapping onion layers of tin foil around your own skull, consider this "option;" they got sick of working on the project, threw some lame page up they slapped together in a few minutes, the end. That's also an option. Maybe the developer got sick of enabling pedophiles and schizophrenics like you and just quit.

Re: Open Source it (1)

epyT-R (613989) | about 1 month ago | (#47151109)

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?

Re: Open Source it (1)

fnj (64210) | about 1 month ago | (#47151455)

Don;t bother arguing substance with the AC moron. He is absolutely clueless.

Re:Open Source it (1)

muridae (966931) | about 1 month ago | (#47151187)

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.

Re:Open Source it (1)

gweihir (88907) | about 1 month ago | (#47150177)

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.

Re:Open Source it (0)

Anonymous Coward | about 1 month ago | (#47152581)

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 [grc.com] is already open source.
It uses the TrueCrypt license.

It is hard to change something into a state it already is in.

How about the build tools and the OS? (1)

T.E.D. (34228) | about 1 month ago | (#47149755)

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 [bell-labs.com] . 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.

Re:How about the build tools and the OS? (3, Insightful)

jcochran (309950) | about 1 month ago | (#47149811)

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... [acsa-admin.org]

Re:How about the build tools and the OS? (1)

T.E.D. (34228) | about 1 month ago | (#47149925)

Interesting idea. But I see two problems there:
  1. 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...
  2. 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.

Re:How about the build tools and the OS? (2)

jcochran (309950) | about 1 month ago | (#47150131)

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.

Re:How about the build tools and the OS? (1)

muridae (966931) | about 1 month ago | (#47151507)

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.

Re:How about the build tools and the OS? (0)

Anonymous Coward | about 1 month ago | (#47152617)

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.

Re:How about the build tools and the OS? (1)

gweihir (88907) | about 1 month ago | (#47150255)

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.

Re:How about the build tools and the OS? (1)

mSparks43 (757109) | about 1 month ago | (#47149893)

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.

Re:How about the build tools and the OS? (0)

Anonymous Coward | about 1 month ago | (#47150049)

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.

Re:How about the build tools and the OS? (1)

gweihir (88907) | about 1 month ago | (#47150263)

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.

Re:How about the build tools and the OS? (1)

muridae (966931) | about 1 month ago | (#47151557)

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.

Re:How about the build tools and the OS? (1)

mSparks43 (757109) | about 1 month ago | (#47151647)

"But only at times the material is actually in use". .....

Or when such key material is encrypted into the file with a master key.....

Re:How about the build tools and the OS? (2)

gweihir (88907) | about 1 month ago | (#47150229)

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... [dwheeler.com]

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.

Re:How about the build tools and the OS? (1)

sexconker (1179573) | about 1 month ago | (#47150503)

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... [dwheeler.com]

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?

Re:How about the build tools and the OS? (2)

idontgno (624372) | about 1 month ago | (#47150571)

Hand-compile, then hand-assemble, and finally poke opcodes into RAM with front-panel switches.

No, I'm not kidding. [stackoverflow.com]

Re:How about the build tools and the OS? (1)

sexconker (1179573) | about 1 month ago | (#47150813)

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?

Re:How about the build tools and the OS? (0)

Anonymous Coward | about 1 month ago | (#47152073)

How would hand compiling and assembling take years?

Switches... (1)

Grog6 (85859) | about 1 month ago | (#47151015)

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

Re:How about the build tools and the OS? (1)

lgw (121541) | about 1 month ago | (#47150637)

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.

Truecrypt fork (2, Informative)

Anonymous Coward | about 1 month ago | (#47149891)

The beauty of opensource is good projects never die.

http://truecrypt.ch/

Re:Truecrypt fork (-1)

scottbomb (1290580) | about 1 month ago | (#47150351)

If I could only trust the Chinese to not build in their own backdoors.

Re:Truecrypt fork (0)

Anonymous Coward | about 1 month ago | (#47150649)

switzerland, not chinese. .ch vs .cn

Re:Truecrypt fork (5, Informative)

Rhymoid (3568547) | about 1 month ago | (#47150697)

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

Will they distrubute the reviewed source (1)

Anonymous Coward | about 1 month ago | (#47149931)

Will they digitally sign a copy of the source they reviewed?
What encryption will be used for the signature? Will anyone trust it?
??????

Pointless (0)

nurb432 (527695) | about 1 month ago | (#47150003)

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

Re:Pointless (2)

Anonymous Coward | about 1 month ago | (#47150123)

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.

Re:Pointless (0)

nurb432 (527695) | about 1 month ago | (#47150373)

I ( and many others ) have to disagree, its not useful any longer, and a security risk.

Re:Pointless (0)

Anonymous Coward | about 1 month ago | (#47151183)

On what basis?

Re:Pointless (3, Interesting)

muridae (966931) | about 1 month ago | (#47151201)

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?

Re:Pointless (5, Interesting)

dave562 (969951) | about 1 month ago | (#47150137)

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.

Re:Pointless (3, Insightful)

epyT-R (613989) | about 1 month ago | (#47151169)

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.

Re:Pointless (0)

Anonymous Coward | about 1 month ago | (#47153335)

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.

Re: BestCrypt is not "random" (3, Interesting)

Anonymous Coward | about 1 month ago | (#47151881)

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

Re:Pointless (0)

Anonymous Coward | about 1 month ago | (#47152511)

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.

Re:Pointless (3, Insightful)

Anonymous Coward | about 1 month ago | (#47150289)

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?

Re:Pointless (1)

nurb432 (527695) | about 1 month ago | (#47150395)

Who said my organization didn't already audit it? And there is more going on here than a simple project abandonment.

Re: Pointless (0)

Anonymous Coward | about 1 month ago | (#47150621)

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.

Re:Pointless (0)

Anonymous Coward | about 1 month ago | (#47150899)

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

Re:Pointless (1)

muridae (966931) | about 1 month ago | (#47151255)

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.

Re:Pointless (1)

Desler (1608317) | about 1 month ago | (#47152119)

Where's the audit and the methodology, then?

TC PROVEN UNSAFE AT ANY SPEED! (-1)

Anonymous Coward | about 1 month ago | (#47150551)

So why? Why? WHY? Go back to FB where you belong!

What to use... (0)

Anonymous Coward | about 1 month ago | (#47150851)

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?

Re:What to use... (1)

epyT-R (613989) | about 1 month ago | (#47151185)

you wouldn't want truecrypt for that anyway as the linux truecrypt runs through FUSE, slowing things considerably.

Re: What to use... (0)

Anonymous Coward | about 1 month ago | (#47153133)

No way, it uses dm-crypt. Please inform yourself before posting bull**it

Technical leads (1)

ThatsNotPudding (1045640) | about 1 month ago | (#47153677)

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)?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...