Beta
×

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!

First Phase of TrueCrypt Audit Turns Up No Backdoors

Unknown Lamer posted about 7 months ago | from the only-slightly-insecure dept.

Encryption 171

msm1267 (2804139) writes "A initial audit of the popular open source encryption software TrueCrypt turned up fewer than a dozen vulnerabilities, none of which so far point toward a backdoor surreptitiously inserted into the codebase. A report on the first phase of the audit was released today (PDF) by iSEC Partners, which was contracted by the Open Crypto Audit Project (OCAP), a grassroots effort that not only conducted a successful fundraising effort to initiate the audit, but raised important questions about the integrity of the software.

The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver; architecture and code reviews were performed, as well as penetration tests including fuzzing interfaces, said Kenneth White, senior security engineer at Social & Scientific Systems. The second phase of the audit will look at whether the various encryption cipher suites, random number generators and critical key algorithms have been implemented correctly."

Sorry! There are no comments related to the filter you selected.

The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46751713)

The only thing we know is that he likes to rape children and needs to be locked up. I encourage everyone to report that sick fuck to the police and get him removed from society until he stops destroying innocent lives. His name is Alexander Peter Kowalski and he lives at 903 East Division St., Syracuse, NY 13208 (he was born 01/31/1965; his mother is Jan Kowalski, born 12/03/1933. I encourage everyone to call his neighbors and warn them that he may have raped and\or murdered their children and uses HOSTS files to evade police detection when he looks at child porn. If anyone lives in his area, I suggest printing out some fliers and stapling them around his neighborhood with a large "PAEDO WARNING!" on the top.

Re:The truth about APK (0)

Anonymous Coward | about 7 months ago | (#46752207)

Utilization of the HOSTS file would not allow you to avoid police detection; it is only useful as an anti-malware tool. Where do you get your information from?

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752319)

The countless children that APK has tortured.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46753193)

More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46753597)

Heh, the more APK goes after his random stalkee du jour, less likely he'll notice who is really messing with him and the easier he is to troll.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46753799)

WIth all the multiple sockpuppets Tom has http://slashdot.org/comments.p... [slashdot.org] has or Zontar http://slashdot.org/comments.p... [slashdot.org] has also? Maybe. It's them that are caught in the act, red-handed though. Like apk caught Barbara, not Barbie = TomHudson long ago. Tom or Zontar, yes we know it's you posting now. Clue: Your ac trolling post now isn't fooling us a bit either. Accept it. You're too stupid to fool anyone. Is your favorite color 'transparent'?>b? Must be. I see right through you.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752749)

It does much more than that for speed, security, reliablity, + anonymity http://start64.com/index.php?o... [start64.com] shown in 17 points there where apk has it hosted along with sites in the security community (like malwarebytes' hpHosts website). Apk's made a good program that does what he stated in that link above in 17 points for the good of any end user of customized host files and that botnet masters and malware makers hate since it stops them dead, saves you bandwidth + tracking advertisers take from you along with infecting you with malicious script, gives you reliablity against DNS redirection flaws from fastflux and dynamic dns using botnets as well as downed dns servers, and even added anonymity against dns request logs or getting past dnsbl you may not like. It doesn't stop police using deep packet inspection or the nsa with their practically man-in-the-middle attack using discrete math graph theory techniques or BGP misuse. However it does more than any single browser addon and even fixes dns security issues with less parts and its native to any OS with a standard bsd derived ip stack.(which is most all out there if not all) for more speed, security, reliablity, and anonymity.

Re:The truth about APK (1)

r.freeman (2944629) | about 7 months ago | (#46752231)

what the fuck did I just read?

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752809)

More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both ,libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

Re:The truth about APK (0)

Anonymous Coward | about 7 months ago | (#46752491)

I am unfamiliar with the drama surrounding apk, but I do know that people who run around accusing others of pedophilia are usually just using it as ad hominem.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752827)

More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both ,libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752607)

Hahahaha, "insta-downmod" (gosh, wonder why - not). More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk).

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752705)

Admit your crimes and turn yourself into the police!

I encourage everyone to report that sick fuck to the police and get him removed from society until he stops destroying innocent lives. His name is Alexander Peter Kowalski and he lives at 903 East Division St., Syracuse, NY 13208 (he was born 01/31/1965; his mother is Jan Kowalski, born 12/03/1933. I encourage everyone to call his neighbors and warn them that he may have raped and\or murdered their children and uses HOSTS files to evade police detection when he looks at child porn. If anyone lives in his area, I suggest printing out some fliers and stapling them around his neighborhood with a large "PAEDO WARNING!" on the top.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752753)

HahahahahaL You got an insta-downmod troll for lies and libel http://it.slashdot.org/comment... [slashdot.org]

Re:The truth about APK (1)

thexfile (3221535) | about 7 months ago | (#46752645)

WTF. A troll with a cause.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46753027)

More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

Re:The truth about APK (0)

Anonymous Coward | about 7 months ago | (#46752743)

The punishment for making this accusation maliciously should be worse than the crime itself.

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752839)

More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both ,libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46752863)

More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... [slashdot.org] or Zontar http://slashdot.org/comments.p... [slashdot.org] (both ,libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

Re:The truth about APK (-1)

Anonymous Coward | about 7 months ago | (#46753913)

I suppose the parent's real name is Alexander Peter Kowalski? Mr Kowalski, a HOSTS file will not help you against police detection. Enjoy your ten seconds of fame.

Wow (3, Informative)

cold fjord (826450) | about 7 months ago | (#46751747)

Wow, a code audit. What a great idea for a FOSS project. [openbsd.org]

Re:Wow (0, Interesting)

Anonymous Coward | about 7 months ago | (#46751779)

The same OpenBSD that shipped an OpenSSL version with the heartbleed bug? Hmmm...

Re:Wow (-1, Redundant)

Anonymous Coward | about 7 months ago | (#46751907)

Right, because every project that has "Open" its name is produced by OpenBSD team.

Like OpenOffice, OpenQuake, OpenStack, OpenCL, OpenStreetMap...

Re:Wow (0, Interesting)

Anonymous Coward | about 7 months ago | (#46751963)

Didn't say or imply that, but they claim to be auditing the code they ship yet seem to have missed the massive bug in one of the major parts of the system when used as a server.

Re:Wow (-1)

Anonymous Coward | about 7 months ago | (#46752111)

It's not a claim, they do audit their code. Oh, you mean they should be auditing everybody else's code too? Why do I get the feeling you're just a whiny bitch?

Re:Wow (2, Interesting)

Anonymous Coward | about 7 months ago | (#46752233)

Oh, you mean they should be auditing everybody else's code too?

Umm, yeah? Since that's what they claim to do:

The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component.

http://www.openbsd.org/securit... [openbsd.org]

Or are you going to claim that OpenSSL is not a critical software component?

Re:Wow (0)

Anonymous Coward | about 7 months ago | (#46752393)

Wow, to think that when they "fail" it only makes them equal to everyone else.

Re:Wow (0)

Anonymous Coward | about 7 months ago | (#46752997)

And bitcoin isn't a Ponzi scheme either....

Re:Wow (0, Interesting)

Anonymous Coward | about 7 months ago | (#46752187)

Ah, ok. It's just I've seen enough "LOL Theo wrote Heartbleed. I mean, OpenSSH, OpenSSL, what's the difference?"-like posts these few days and jumped to conclusions. Still, I don't see it painting them as liars.

It took half a year for this first phase of audit of one package to complete - imagine how long would a single point release take with comprehensive audit of every package? They do find and fix bugs in 3rd party packages, but of course they can't catch every bug when they're limited by resources and time and stretched over every part of OS.

Re:Wow (1)

Anonymous Coward | about 7 months ago | (#46751799)

Difference between an Internal and External audit.

Nothing like $140k to vet opensores (-1)

Anonymous Coward | about 7 months ago | (#46751761)

Talk about malpractice expense!

Phase 2: ?

Phase 3: profit!

Re:Nothing like $140k to vet opensores (2)

epyT-R (613989) | about 7 months ago | (#46752501)

at least the sores are open, so that one may take a puss sample and analyse it for disease. When the sores are closed, who knows what you'll wake up with in the morning.

http://www.linuxadvocates.com (-1)

Anonymous Coward | about 7 months ago | (#46751767)

Dear Linux Advocate,

Money doesn't grow on trees. And, Linux Advocates is growing. Naturally, we anticipate operating costs and hope to be able to meet them.

But, any amount you feel you are able to donate in support of our ongoing work will be most surely appreciated and put to very good use. Your contributions keep Linux Advocates growing.

Show your support by making a donation today.

Thank you.

Dieter T. Schmitz
Linux Advocates, Owner

http://www.linuxadvocates.com/... [linuxadvocates.com]

To Crypt or Not To Crypt (0)

Anonymous Coward | about 7 months ago | (#46751773)

Think I honed a few TC segments in Olly a while back, but nothing serious. I'd much rather have a few bugs than intentional back-doors. Fix those severe bugs described in he audit release and you got yourself user for life, TC.

Re:To Crypt or Not To Crypt (2)

WaywardGeek (1480513) | about 7 months ago | (#46752449)

I use TrueCrypt. Not that it likely matters given all the other back-doors on my Lenovo Wintel laptop, but I use a passphrase from Hell, and I suspect even the NSA's biggest cracker would have trouble with it.

Other than the backdoors in various places on this toxic waste dump of security, the biggest security threat to my passphrase from Hell is TrueCrypt itself. TrueCrypt by default does 100% useless password strengthening (key stretching or whatever it's called). It's strongest mode, which you have to select manually, is 2000 rounds of SHA-256. I can buy SHA256 boxes that do 1 Giga-hash/second per $10. Figure a government has a few million at least for such boxes, and go compute how strong your password needs to be, and it isn't pretty.

I use my password and TrueCrypt to protect my data. Why didn't it occur to the TrueCrypt authors to protect my password? I mean, Bcrypt at least, come on...

Re:To Crypt or Not To Crypt (2)

cbhacking (979169) | about 7 months ago | (#46753395)

A good strong PBKDF2 is probably sufficient, but yeah, 2k rounds is pathetic. iPhones were doing better (admittedly, their passphrases tend to be very short) several years ago, and that's on a mobile CPU. Having a limit of 2k rounds doesn't even make sense, it's not like it's harder to code it for more rounds or something. The only real limit should probably be 0xFFFFFFFF rounds (assuming 32-bit ints) because why have a limit at all?

Hard to understate (2, Insightful)

Anonymous Coward | about 7 months ago | (#46751775)

just important this audit is...

Re:Hard to understate (2, Informative)

wonkey_monkey (2592601) | about 7 months ago | (#46754263)

Hard to understate

It's not really important at all.

There, that was easy.

Or, assuming the AC meant "overstate":

Without this audit the lives of every person on this planet are doomed to end in fiery death when the Earth plummets into the Sun in 2017!

Also easy.

Technically if an NSA backdoor existed (1, Insightful)

WillAffleckUW (858324) | about 7 months ago | (#46751853)

Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.

So, what we can say is that it's clean, insofar as they are permitted to report.

Verify, then trust.

Re:Technically if an NSA backdoor existed (1, Insightful)

Anonymous Coward | about 7 months ago | (#46751921)

Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.

So, what we can say is that it's clean, insofar as they are permitted to report.

Verify, then trust.

"Finally, iSEC found no evidence of backdoors or otherwise intentionally malicious code in the
assessed areas" - so I guess they are permitted to lie.

Re:Technically if an NSA backdoor existed (1)

2fuf (993808) | about 7 months ago | (#46752639)

> I guess they are permitted to lie

one doesn't need permission to do it anyway

Re: (1)

Anonymous Coward | about 7 months ago | (#46751943)

ITT: People who (a) don't know how US law actually works and (b) assume that everyone in the world is bound by US law.

Re:Technically if an NSA backdoor existed (3, Interesting)

masonc (125950) | about 7 months ago | (#46751955)

The code is being audited in America. That's pretty funny.
How about an audit in a country where the NSA cannot tell the auditors to shutup?

Re:Technically if an NSA backdoor existed (0)

WillAffleckUW (858324) | about 7 months ago | (#46752065)

See, that's my point.

The audit needs to occur in a place that does not utilize the backdoors the NSA and GCHQ and other agencies are.

Which rules out Canada, the UK, and the USA.

At the bare minimum.

Verify. Then trust.

Re:Technically if an NSA backdoor existed (2, Insightful)

Anonymous Coward | about 7 months ago | (#46752077)

And Germany and France and South Korea and Japan and Brazil and China and Australia and New Zealand, etc. Or do you honestly think only those 3 countries spy on their citizens?

Re:Technically if an NSA backdoor existed (1)

WillAffleckUW (858324) | about 7 months ago | (#46752149)

True. I for one know that Australia and China definitely do.

My point is that you need to set it up so that you have three auditors for each part, each in a different "security" region.

And give them "unsafe" code words to embed in a place where other auditors can see if they have been compromised.

Has to be done in a sealed room without electricity, of course (or at least no circuits in) when you set up the code words.

Otherwise, we had the technology in the 80s to hear it, so I can guarantee we can still hear it.

Technically they would have to disrobe and shower and scrub if you really wanted to be safe.

(thinking about this makes it sound like an episode of Get Smart ....)

Verify. Then trust.

Re:Technically if an NSA backdoor existed (2)

viperidaenz (2515578) | about 7 months ago | (#46752327)

Why does it rule those countries out?
You you perform your audits in all 3 countries, the only things being missed are backdoors put in by all 3 securities agencies cooperating together.
Add in China or some other "we don't like USA" country and you get better odds.

Re:Technically if an NSA backdoor existed (1)

WillAffleckUW (858324) | about 7 months ago | (#46752373)

No, my point is that you can't choose three countries which work together to spy on their citizens - for example, choosing Canada, US, and UK would be self-defeating.

You need one in each region, so that the "odd man out" will be obvious when it "fails" to report a flaw the other two report.

Re:Technically if an NSA backdoor existed (0)

Anonymous Coward | about 7 months ago | (#46753171)

And what if a security agency discovers a backdoor they didn't put in themselves? Even if they are against the country that put it in, they may not be interested in sharing information about that backdoor if they could still use it one way or another.

Re:Technically if an NSA backdoor existed (1)

PopeRatzo (965947) | about 7 months ago | (#46752601)

The code is being audited in America.

Is there something preventing an audit elsewhere? Is it illegal to send the source code overseas? And how are these audits done? There aren't a lot of details in TFA. Is it like a big Wiki where anybody can look at the code and report what they find, or are the auditors vetted with specific sections assigned them?

I'm asking seriously. I'm not a developer, so I don't know. But I worry about security and snooping.

Re:Technically if an NSA backdoor existed (4, Interesting)

techno-vampire (666512) | about 7 months ago | (#46751983)

Tell me this: if the NSA did put a backdoor in the package and if this audit found it, how would the NSA know about it in time to prevent it being reported? Sending a security letter to the auditors would just be considered proof that there was a backdoor to be hidden. The auditors may have been forced not to reveal anything about it to the general public, but you can bet that the people over at TrueCrypt would have found out about it and eliminated it as soon as possible, although they'd probably have had to pretend that they found the flaw themselves to protect both themselves and the auditors.

Re:Technically if an NSA backdoor existed (1)

ewibble (1655195) | about 7 months ago | (#46752107)

Um put an agent inside iSEC, although we know the NSA would above that. Spying is not their job.

Re:Technically if an NSA backdoor existed (0)

Anonymous Coward | about 7 months ago | (#46752189)

Well the prudent thing would be to send a letter as soon as the audit was organized, before they had time to uncover anything.

Re:Technically if an NSA backdoor existed (0)

Anonymous Coward | about 7 months ago | (#46752711)

The second sentence addresses that very situation. Do you need a dopey YouTube video to read it out for you?

Re:Technically if an NSA backdoor existed (0)

Anonymous Coward | about 7 months ago | (#46754035)

So IOW, the NSA could send a letter regardless and ruin the trust people place in TrueCrypt?

Re:Technically if an NSA backdoor existed (1)

Antique Geekmeister (740220) | about 7 months ago | (#46752771)

The NSA was _able_ put in back doors. According to the report, the build environments were not safe enough and well enough controlled, or verified, to _prevent_ back doors. Given the NSA's strong interest in having one, and their level of skill, I'm afraid I'd have to assume that they did, indeed, create one. Whether a system that is at risk of such a back door is good enough for personal or even business is something you'd have to decide on a personal basis.

It does seem a good step in the right direction for open source tools to _get_ a thorough security audit, rather than merely relying on "many eyes" to ensure security.

Re:Technically if an NSA backdoor existed (5, Insightful)

vux984 (928602) | about 7 months ago | (#46751989)

Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.

Two responses.

First, I suspect if they were confronted with an NSL they could go the lavabit route and simply suspend the audit project with no explanation. IANAL but I don't think the NSA can compel them to falsify the audit results.

Second, if they are smart, they can have it audited multi-nationally with independent auditors to make it harder for any government gag orders to stick.

Re:Technically if an NSA backdoor existed (4, Interesting)

Charliemopps (1157495) | about 7 months ago | (#46752243)

The problem with the NSA is we have no idea what their capabilities are, technologically or legally. They are clearly violating the constitution already and there seems to be no one willing or capable of stopping them. So if they did come to you with a NSL, no matter how ridiculous or unconstitutional it was, what choice would you have? You could go to the media, but how embedded in the media are they? Do they have standing NSLs with all the media organizations out there? You could go outside the country, but those newspapers are government by their own countries version of the NSA who's working in close relationship with ours. This really is a Global totalitarian secret police state. They haven't started herding people into camps or anything, but really... what's to stop them?

Re:Technically if an NSA backdoor existed (4, Insightful)

vux984 (928602) | about 7 months ago | (#46752325)

Do they have standing NSLs with all the media organizations out there?

I think there'd be less Snowden leak coverage if there were. :)

You could go outside the country, but those newspapers are government by their own countries version of the NSA who's working in close relationship with ours

Like China & Russia? Governements want their own security as much as their own intelligence agencies want to break it... there's too many pieces moving in opposite directions for there to be a credible global coverup of a transparent audit of open source software.

Re:Technically if an NSA backdoor existed (1)

ColdWetDog (752185) | about 7 months ago | (#46752915)

Oh just post it on Slashdot. We'll do the rest.

Re:Technically if an NSA backdoor existed (0)

VortexCortex (1117377) | about 7 months ago | (#46753045)

The problem with the NSA

The problem with the NSA is the same as all other problems: They Exist.

Government agencies have long since proven they can't be trusted with secrecy. [wikipedia.org] A secret oversight committee just moves the problem around.

Re:Technically if an NSA backdoor existed (1)

Anonymous Coward | about 7 months ago | (#46753433)

...what's to stop them?

Fear of American Citizens who have not yet disarmed.

Re:Technically if an NSA backdoor existed (0)

cold fjord (826450) | about 7 months ago | (#46753729)

. They are clearly violating the constitution already and there seems to be no one willing or capable of stopping them.

They are only "violating" the cartoon version of the constitution. The real Constitution is doing ok, at least for this issue.

This really is a Global totalitarian secret police state. They haven't started herding people into camps or anything, but really... what's to stop them?

Do you have any links to info about those "FEMA death camps" you care to share?

Re:Technically if an NSA backdoor existed (-1, Troll)

r.freeman (2944629) | about 7 months ago | (#46752259)

Didn't the democracy of USA written a law that you can imprison who ever for what ever reason, and without trial, for indefined time?
Noble Prize Winner, War Criminal, Obama signed this law into existance as NDAA.
Did something changed? That sounds like a quite compeling argument.

Why are we trusting a Republican group? (-1)

Anonymous Coward | about 7 months ago | (#46751863)

They already fucked us over once to help their friends at Microsoft. Why trust them again? I bet Bush and his crew are using this as an opportunity to add even more back doors. This is what their kind does. They are disgusting and should be shunned by our community.

Re:Why are we trusting a Republican group? (1)

epyT-R (613989) | about 7 months ago | (#46752527)

Why would you trust the liberals? I wouldn't trust either.

Re:Why are we trusting a Republican group? (1)

kwbauer (1677400) | about 7 months ago | (#46753631)

Due, Bush has been out of office for 6 years now. I know things are moving fast but please do try to keep up.

also (1)

JustNiz (692889) | about 7 months ago | (#46751897)

Since Snowden's revelation about the NSA's clandestine $10 million contract with RSA,
  I hope that as well as checking that the code implements some known encryption algorithm properly, that they also confirm that the algorithm itself is mathematically unadulterated (by the NSA or whoever).

Re:also (5, Insightful)

Shakrai (717556) | about 7 months ago | (#46751971)

Since Snowden's revelation about the NSA's clandestine $10 million contract with RSA,

If you're on NSA's radar you've got bigger problems than TrueCrypt's trustworthiness or lack thereof. The NSA doesn't have to have a back door into AES (or the other algorithms) when they have an arsenal of zero day exploits, side channel attacks, social engineering, and TEMPEST techniques at their disposal. The average user should be far more concerned about these attack vectors (from any source, not just NSA) than the security of the underlying encryption algorithm.

The Diceware FAQ [std.com] sums up the problem rather succinctly: "Of course, if you are worried about an organization that can break a seven word passphrase in order to read your e-mail, there are a number of other issues you should be concerned with -- such as how well you pay the team of armed guards that are protecting your computer 24 hours a day."

Re:also (4, Interesting)

rahvin112 (446269) | about 7 months ago | (#46752169)

Oh hell, they'll just sneak into your home in the middle of the night and plant a hardware bug or key logger into your computer.

One of their favorite tactics used by law enforcement is to install cameras in your residence facing where you normally use your computer. They got a child pornographer like this, his use of true crypt didn't help because they had video of him entering the password and simply entered the password once they seized the computer.

True Crypt cannot reasonably protect you from law enforcement nor state sponsored spying like the NSA. It might protect you from some non-tech police agency in some shit hole country being able to access it but then they just use the standard non-tech password extraction method.

Obligatory XKCD. http://xkcd.com/538/ [xkcd.com]

Re:also (0)

Anonymous Coward | about 7 months ago | (#46752917)

One of their favorite tactics used by law enforcement is to install cameras in your residence facing where you normally use your computer.

Paranoid much?

Re:also (3, Insightful)

Kjella (173770) | about 7 months ago | (#46752881)

If you're on NSA's radar you've got bigger problems than TrueCrypt's trustworthiness or lack thereof.

In case you've been sleeping under a rock for the last year, the target of the NSA is everyone. Not that they put you on the same level as the Chinese military of course, but nobody's under their radar and if they can grab your data or metadata easily they will because you could be a terrorist or at least the friend of a friend of a friend of a terrorist. It's not that the average joe would stand a chance if they threw everything in their arsenal at us, but those "zero day exploits, side channel attacks, social engineering, and TEMPEST techniques" don't come free and using them highly increases the chances of exposing them. The question is more like "Does NSA grab all the TrueCrypt containers used as backup on Dropbox/GDrive/whatever and rifle through everyone's data?" than "If the NSA really wants the contents of my laptop, would this really stop them?"

Re:also (2)

Lost Race (681080) | about 7 months ago | (#46753443)

Snowden basically walked out of the NSA with all their secrets; who's to say a few dozen or hundred other contractors didn't do the same thing before him? Everything the NSA knew or had access to before 2013 was most likely available in blackhat circles through clandestine leaks.

Any backdoors in TrueCrypt would be a security disaster, and the NSA has already proven itself willing and able to put backdoors in highly trusted security software. It's also proven itself incapable of keeping secrets.

Worrying about NSA-planted vulnerabilities is not the same thing as worrying about a direct attack from the NSA itself.

A triumph for FOSS (2)

FuzzNugget (2840687) | about 7 months ago | (#46751929)

This is why open source is so important.

Re:A triumph for FOSS (4, Insightful)

jones_supa (887896) | about 7 months ago | (#46753837)

No. This is why thorough code audits are important.

Re:A triumph for FOSS (2)

Warbothong (905464) | about 7 months ago | (#46754619)

This is why open source is so important.

How so? TrueCrypt is neither Open Source or Free Software. It's freeware (ie. proprietary).

Bootloader & Windows Driver (4, Insightful)

Anonymous Coward | about 7 months ago | (#46751945)

The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver. Not really surprising that they didn't find any critical security issues in those parts. The high value bugs should be in the crypto parts and how they are implemented.

Re:Bootloader & Windows Driver (-1, Troll)

masonc (125950) | about 7 months ago | (#46752019)

The words "American" and "security" cannot be used in the same sentence. There is nothing American that can be secure, just as there is nothing "American" and "Offshore Bank Account" that can ever be used in the same sentence. If you are American, then accept that you are bound to obey the Government, pay your taxes and deny climate change. It's the American way!
Anyone hiring an American to security audit code is either stupid or naive.

Re:Bootloader & Windows Driver (2, Informative)

Anonymous Coward | about 7 months ago | (#46752117)

What? I should probably assume you are joking, but in case you are not:

This is a stupid statement. If someone is American and they have a bank account in another country, both are able to be true. They are an American with an off shore bank account. Similarly, just because the NSA is American and have impacted the concept of security does not mean that Americans can not evaluate or produce secure code. And just to be more antagonizing than you are being, guess what? you used 'American' and 'security' in the same sentence while trying to explain that its impossible to do so. In fact, the NSA is an American agency and I would say that they have been leading the way in developing methods of intrusion, and circumventing security. So clearly Americans understand security so well, we know how to get around what exists today. Anyone hiring you for anything other than to take food orders is either stupid or naive.

Re:Bootloader & Windows Driver (2)

viperidaenz (2515578) | about 7 months ago | (#46752341)

It depends why you're hiring an American to do your security audit.

Is it stupid for someone in China to hire an American to look for back-doors that may have been added by a Chinese Government agency?

Re:Bootloader & Windows Driver (3, Informative)

epyT-R (613989) | about 7 months ago | (#46753091)

The crypto is implemented in the driver, as well as the bootloader. The application known as truecrypt just flips their configuration bits around, loads keys into ram, and tells the driver when to mount/dismount containers etc. The bootloader needs to know enough to mount the system partition and hook into BIOS so that the regular OS bootloader can take over using it's normal calls. Once it loads the kernel and related drivers, truecrypt.sys takes over handling container IO.

  The separate formatting utility probably contains some too since it's used to create containers..

what about compilers ? (2, Insightful)

Anonymous Coward | about 7 months ago | (#46752009)

isn't it possible to just have your backdoor be inserted by the compiler ?

Re:what about compilers ? (1)

r.freeman (2944629) | about 7 months ago | (#46752287)

Yeap, that is an option. Dunno which idiot mod downvoted your insightfull question and why...

Re:what about compilers ? (0)

Anonymous Coward | about 7 months ago | (#46752353)

I modded this statement as Redundant, it's similar to claiming water is wet or fire is hot.

If you've read the report you'd know the auditors are addressing the question of traceability of the compilation.

Re:what about compilers ? (0)

Anonymous Coward | about 7 months ago | (#46752621)

Off topic. If there's a backdoor in the compiler, then guess what? That's a problem with the compiler, not TrueCrypt. I'm not sure why anyone would think that would show up in TC's sourcecode.

Re:what about compilers ? (0)

Anonymous Coward | about 7 months ago | (#46754037)

It's not off topic. It would not be in the source, but it would be in the binary that most people use, so it is very much to the subject.

memset() is bad? (5, Interesting)

Anonymous Coward | about 7 months ago | (#46752055)

I've been coding in C a long time and one of the medium security faults makes no sense to me:
"Windows kernel driver uses memset() to clear sensitive data"
The reasoning they give is:
"...However, in a handful of places, memset() is used to clear potentially sensitive data. Calls to memset() run the risk of being optimized out by the compiler."

WTF?!?
I suppose a smart compiler can optimize out a memset() if it's directly preceeded by a calloc() or something, but I have never had any compiler ever just ignore my request to memset().
What am I missing here?

Re:memset() is bad? (4, Informative)

Anonymous Coward | about 7 months ago | (#46752271)

Re:memset() is bad? (2)

theskipper (461997) | about 7 months ago | (#46752407)

Great article. Including the openssl bug(s) he pointed out...was expecting something esoteric but turned out to be really straightforward i.e. the type of error you make at 2am, taking the size of the pointer instead of the actual size of the buffer.

Re:memset() is bad? (2, Informative)

Anonymous Coward | about 7 months ago | (#46752273)

https://www.securecoding.cert.org/confluence/display/cplusplus/MSC06-CPP.+Be+aware+of+compiler+optimization+when+dealing+with+sensitive+data

Re:memset() is bad? (5, Informative)

canajin56 (660655) | about 7 months ago | (#46752295)

As a special case, MSVC++ removes memset(array,value,sizeof(array)) if array isn't read again before the end of its scope.

For example

void Foo()
{
char password[MAX_PASSWORD_LEN];
InputPassword(password);
ProcessPassword(password);
memset(password, 0, sizeof(password));
}

The MS compiler will delete the memset. In Windows you should use RtlSecureZeroMemory to zero out memory you want to keep secure.

Re:memset() is bad? (0)

Anonymous Coward | about 7 months ago | (#46752303)

It sounds as though they're concerned that the compiler may optimize away a memset used to sanitize a block of memory immediately before freeing it. I would imagine that if the compiler can prove that a read does not occur (or, perhaps even has no side-effects) after a write, it would be legal to optimize that write away. Though, IANAL(anguage)L.

Re:memset() is bad? (4, Interesting)

philcolbourn (1150439) | about 7 months ago | (#46752307)

Say you store a password in a memory buffer. Use it. Then overwrite it with a call to memset. If this buffer is never used again, a compiler may think this is a wasted write and optimise-out this call to memset.

Re:memset() is bad? (1)

viperidaenz (2515578) | about 7 months ago | (#46752357)

If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?

Re:memset() is bad? (1)

rdnetto (955205) | about 7 months ago | (#46754563)

If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?

The longer the data remains in memory, the wider the window to read it via some other exploit. (Also, anything running as root could potentially access it.) This is precisely what happened with Heartbleed.

Re:memset() is bad? (1)

fisted (2295862) | about 7 months ago | (#46752629)

No idea why the paper talks about the compiler optimizing it out, that's obviously wrong. However, in the next paragraph, it reveals that swapspace is the reason. You might, after the page fault and swap-in, initialize the buffer via memset -- however this doesn't erase the previous data from swap space. Apparently, some "secure" memset-like routine does that.

It Assumes Bounds Checking without Implementing It (2)

Sanians (2738917) | about 7 months ago | (#46754647)

WTF?!?

WTF indeed.

There seems to be a major trend towards making compilers create code that is as different as possible from what the programmer wrote without being so different that the programmer actually notices. One might assume it's a secret NSA plot to defeat security measures in all software everywhere. You know, if one was incredibly paranoid, that is.

It's hard to say whether this is justified behavior. As an example, consider this code from a link an AC posted [viva64.com] :

int
crypto_pk_private_sign_digest(....)
{
    char digest[DIGEST_LEN]; ....
    memset(digest, 0, sizeof(digest));
    return r;
}

Exploit mitigation code like this is a case of writing code which we expect to never have any effect, just in case we're wrong and it does have an effect. Then the compiler comes along and decides for itself that the code we wrote will never have any effect and removes it. It's kind of hard to blame it for noticing the uselessness of the operation when we ourselves expected the code to likely have no effect when we wrote it, but then, the whole reason we wrote it is because we thought we might be wrong. Should the compiler then assume that we might be wrong as well, and that we might access that memory using a different pointer?

Does it make sense to compile with optimization enabled when, by including things like the memset() call to clear memory we're finished using, we clearly have goals other than optimization?

The article mentions the fix being the use of a different function which won't be optimized away, but I wonder if even that is a legitimate fix. Our "digest" array is just another variable that the compiler is free to do whatever it wants with in the name of optimization. If it will make the program run faster, it's free to make two copies of it. Then our new never-optimized-away function will end up erasing only one copy of the variable.

So problem here isn't the use of memset() rather than some other function. The problem is that we're asking the compiler to create code that doesn't match what we've written. It should be no surprise then when it goes ahead and does that. Thus, I don't think it's correct to claim that the error here is the failure to use the correct function to clear the memory. I think the error is in asking the compiler to generate code that isn't identical to the source code.

The core of the problem is that C isn't a language that allows us to clearly tell the compiler exactly what we want to happen. Without bounds checking on pointer use, every pointer is effectively a pointer to all memory. Thus, when a pointer falls out of scope, it doesn't mean anything. That memory can still be accessed via any other pointer anywhere in the program. If C enforced bounds checking, such that accessing the data in "digest" via any other pointer was impossible, then the compiler could safely work under the assumption that once "digest" falls out of scope, the data it points to will never be accessed again, and thus removing the memset() call would be a safe thing to do since it truly would have no effect.

It really seems ridiculous when you think about it. Compilers assume that bounds on pointers will be respected, yet make no attempt whatsoever to enforce those bounds, essentially guaranteeing that they will not be respected since programmers are imperfect.

Consider what the compiler will do when it encounters code like this:

int a[4];
int b[4];
int c[4];
b[-1] = 0;

Despite the obvious error in the above code, GCC will compile it without error. It will then perform optimizations that assume that neither a[] nor c[] have been affected by the assignment to b[]. It seems rather ridiculous that anyone is expected to create secure software in such an environment. Either the compiler should enforce bounds checking, or it should assume that any pointer operation can affect any variable.

C could really use an extension for bounds checking. Even if it is purely optional, like a new type of pointer that includes a limit. In many cases the compiler could enforce the bounds at compile time simply by analyzing the program as it currently does when optimizing and so no additional machine code would be generated. In other cases, I think the security benefits would be worth the loss in efficiency. With bounds checking, the compiler could safely optimize away all of those memset() calls and other things programmers do to mitigate security issues since it would then actually know with certainty that the memory being cleared will never be accessed after the variable falls out of scope.

As things are now, we're currently benefiting from those optimizations despite not having modified the language such that the compiler can truly know that those optimizations are safe. Even without modifications to the language, the compiler should at least point out violations in how it assumes the programmer uses pointers, like the assignment in the code above. To optimize under the assumption that the programmer doesn't do such things while ignoring obvious violations of that assumption seems rather negligent.

The Next Question (0)

Nom du Keyboard (633989) | about 7 months ago | (#46752229)

The next question to answer is: Can Heartbleed compromise True Crypt?

The backdoor is not in the source (3)

kbg (241421) | about 7 months ago | (#46752467)

The backdoor is not in the source it is in the MVC++ compiler. NSA is not stupid, putting the backdoor in the source itself would be risky, it would be much wiser to put the backdoor in the MVC++ compiler itself.

Port to GCC, then ensure no backdoors in GCC (5, Interesting)

tepples (727027) | about 7 months ago | (#46752893)

One way to detect a backdoored compiler to a fairly high certainty is diverse double-compiling [dwheeler.com] , a method described by David A. Wheeler that bootstraps a compiler's source code through several other compilers. For example, GCC compiled with (GCC compiled with Visual Studio) should be bit for bit identical to GCC compiled with (GCC compiled with Clang) and to GCC compiled with (GCC compiled with Intel's compiler). But this works only if the compiler's source code is available. So to thwart allegations of a backdoor in Visual Studio, perhaps a better choice is to improve MinGW (GCC for Windows) or Clang for Windows to where it can compile a working copy of TrueCrypt.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?