The TrueCrypt website has been changed it now has a big red warning stating "WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues". They recommend using BitLocker for Windows 7/8, FileVault for OS X, or (whatever) for Linux. So, what happened? The TrueCrypt site says:
This page exists only to help migrate existing data encrypted by TrueCrypt. The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP. Windows 8/7/Vista and later offer integrated support for encrypted disks and virtual disk images. Such integrated support is also available on other platforms (click here for more information). You should migrate any data encrypted by TrueCrypt to encrypted disks or virtual disk images supported on your platform.
Did the TrueCrypt devs (or SourceForge?) get a NSL? They are offering a "new" version (7.2), but apparently the signing key has changed and a source code diff seems to indicate a lot of the functionality has been stripped out. What's up?
Related Stories
According to a German researcher, Mattias Schlenker, we are to expect that the reason for TrueCrypt's recent shutdown is not a National Security Letter, but a serious security flaw in how TC container files are created on Windows.
He expects the flaw to become public within a week.
What gives this chap some credibility is that he's one of the developers of "desinfec't", a Knoppix-based live Linux that comes with several virus scanners and is distributed by well-renowned German computer magazine c't (whose mother company/publishing house, Heise, hosts the forum where he made his announcement).
Link to his original German posting: http://www.heise.de/security/news/foren/S-Re-Warum -TrueCrypt-nicht-in-Desinfec-t-enthalten-ist/forum -280432/msg-25289876/read/
See our earlier coverage: TrueCrypt Discontinued, Compromised.
In an update to the speculation that TrueCrypt development was officially discontinued as a response to efforts by US intelligence agencies to compromise the project, the TrueCrypt web site seems to contain a secret message warning potential users of NSA interference in the integrity of the software. The apparent message, "Don't use TrueCrypt because it is under the control of the NSA" is read as an acrostic in Latin, contained in the message announcing developer cessation of the project on SouceForge. Two independent analytical exercises, conducted independently, arrive at the same conclusion. User "Badon" at the Live Business Chat message board has a detailed exegesis including screenshots and footnotes.
[EDITOR'S NOTE: I have cross checked this on some Latin specific sites, and the consensus seems to be that it is nonsensical from a perspective of proper Latin grammar and syntax. However, Google Translation does reproduce these results. I can certainly believe that a warning might have been composed using G.T. rather than by consulting a classicist. --ED]
Last month, SoylentNews reported that TrueCrypt was discontinued. Many have speculated that a fork would happen, but the TrueCrypt license makes that complicated. Now, Ars Technica reports about contact with a TrueCrypt developer on the subject:
In the days immediately following last month's TrueCrypt retirement, Johns Hopkins University professor Matt Green asked one of the secretive developers if it would be OK for other software engineers to use the existing source code to start an independent version. The developer responded:
"I am sorry, but I think what you're asking for here is impossible. I don't feel that forking truecrypt would be a good idea, a complete rewrite was something we wanted to do for a while. I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of truecrypt's current codebase.
I have no problem with the source code being used as reference."
So, it looks like a fork won't happen after all. But a commenter there noted the existence of FreeOTFE, and I had previously noted tc-play. So even without a TrueCrypt fork, maybe developers won't have to start completely from scratch.
[Ed'sNote: At the time of posting, the Wikipedia entry for FreeOTFE notes that the domain has been dormant for some time. Whether work continues on FreeOTFE is uncertain. The concept sounds very much like the full disk encryption that has been available for linux for quite some time, but which does not provide plausible deniability. If I am wrong in these assumptions, I would welcome being corrected!]
Open Crypto Audit Project has completed "Phase II" (PDF) of its audit of the TrueCrypt source code. The security audit of TrueCrypt, a freeware disk encryption utility, was crowdfunded in October 2013, before the TrueCrypt Foundation's mysterious shutdown on May 28, 2014. In his blog post describing the findings, Matthew Green says:
The TL;DR is that based on this audit, Truecrypt appears to be a relatively well-designed piece of crypto software. The NCC audit found no evidence of deliberate backdoors, or any severe design flaws that will make the software insecure in most instances.
That doesn't mean Truecrypt is perfect. The auditors did find a few glitches and some incautious programming -- leading to a couple of issues that could, in the right circumstances, cause Truecrypt to give less assurance than we'd like it to.
The most significant issue found involved TrueCrypt continuing to generate keys in a rare instance where the Windows Crypto API fails to initialize. This is not necessarily insecure because TrueCrypt "still collects entropy from sources such as system pointers and mouse movements."
In addition to the RNG issues, the NCC auditors also noted some concerns about the resilience of Truecrypt's AES code to cache timing attacks. This is probably not a concern unless you're [performing] encryption and decryption on a shared machine, or in an environment where the attacker can run code on your system (e.g., in a sandbox, or potentially in the browser). Still, this points the way to future hardening of any projects that use Truecrypt as a base.
One project that could benefit from the audit's findings is VeraCrypt, a freeware fork of TrueCrypt licensed under the Microsoft Public License and also subject to the TrueCrypt License, which uses a substantial amount of TrueCrypt code. Matthew Green has speculated that the intent of the TrueCrypt developers' licensing and shutdown decisions was to stir uncertainty over the project and force new disk encryption projects to start from scratch.
For additional analysis of the audit, see the articles by ArsTechnica's Dan Goodin, the Register and Threatpost.
VeraCrypt security audit reveals many flaws, some already patched [Zeljka Zorz/Helpnet Security]
VeraCrypt, the free, open source disk encryption software based on TrueCrypt, has been audited by experts from cybersecurity company Quarkslab.
The researchers found 8 critical, 3 medium, and 15 low-severity vulnerabilities, and some of them have already been addressed in version 1.19 of the software, which was released on the same day as the audit report.
The code auditing effort analyzed VeraCrypt 1.18 and its bootloaders.
"A first step consisted in verifying that the problems and vulnerabilities identified by iSec and NCC Group in TrueCrypt 7.1a for the Open Crypto Audit Project had been taken into account and fixed," the Quarkslab researchers involved in the effort explained.
"Then, the remaining study was to identify potential security problems in the code specific to VeraCrypt. Contrary to other TrueCrypt forks, the goal of VeraCrypt is not only to fix the public vulnerabilities of TrueCrypt, but also to bring new features to the software."
A short overview of the issues found (fixed and still not fixed) can be found here. The audit report, with mitigations for still unpatched vulnerabilities, can be downloaded from here.
Are any Soylentils using Veracrypt and/or other forks of Trucrypt?
The full audit report: TrueCrypt Cryptographic Review[PDF] [Alex Balducci, Sean Devlin, Tom Ritter/Open Crypto Audit Project]
Previously:
Independent Audit: Newly Found TrueCrypt Flaw Allows Full System Compromise
No Backdoors Found in TrueCrypt
TrueCrypt Site Encodes Warning about NSA Infiltration
TrueCrypt Discontinued, Compromised?
-- submitted from IRC
(Score: 5, Funny) by aristarchus on Thursday May 29 2014, @04:27AM
Red Flag! Run away!!!
"It's only a bunny."
"But that rodent has a mean streak a mile wide! Look at all the bones"
"You're a looney."
So how could Microsoft's end of support for XP have anything to do with an encrypted file format? Only if that file format was actually a catepillar pretending to be a snake on a iPhone held hostage in Oz. I swear, the world just keeps getting stranger each and every day. And I am more and more smug that I only use Linux, Free Software encryption the only t oahtthalhglkhfk;ngkm,njhovahv,anv,!!
(Score: -1, Offtopic) by Anonymous Coward on Thursday May 29 2014, @04:34AM
It's overpopulation, man! There are too many people! With too many ideas in their stupid bulbous heads!
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @06:04AM
Who choose to spout those ideas anonymously on websites.
OMG I'm doing it too! All is lost.
(Score: -1) by Anonymous Coward on Thursday May 29 2014, @06:25AM
Lazy people can't be arsed to create an account!
(Score: 1, Offtopic) by aristarchus on Thursday May 29 2014, @07:01AM
Hey, all you lazy AC's! I have an account! I may be hiding behind a fake email that is proxied and tor'ed to the max, but I least I take a stand! (what were we taking about?)
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @07:14AM
If you're hiding you'd be posting AC, you karma whore, karma whore, karma whore.
(Score: 2, Offtopic) by aristarchus on Thursday May 29 2014, @07:42AM
Point taken. (Hanging head in shame, made worse by the fact that I have an account, I have karma to lose, a reputation to preserve, a kingdom to rule, and, wait, nothing really matters. (Don't you really hate it, when you are of a certain age, that you can be trapped between Bohemian Rhapsody a la' Queen, and Disney's latest Princess film? The flaming never bothered me, anyway! (. . . I'm just a little silouette of a man, Scharamoche. . . . Let it go!! Let it go!!!)
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @02:53PM
))
There you go.
(Score: 2) by nightsky30 on Friday May 30 2014, @12:00PM
Thank you.
(Score: 4, Insightful) by tangomargarine on Thursday May 29 2014, @02:34PM
It's not paranoia if they really are out to get you.
Seems like the best way to communicate with users in the event of getting shut down with an NSL involved would be to give a reason that is obviously bullshit. They can compel you to not mention the NSL, but they can't compel you to say anything else, right? ("can't"...)
And anyone who uses 7.2 without someone doing a comprehensive code review is obviously a fool.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @04:27AM
Maybe they found bugs they can't fix. Sometimes inherent design flaws cause entire projects to be abandoned. At least there's an announcement.
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @04:30AM
Ya, they should have just abandoned it and let it rot.
(Score: 3, Insightful) by Anonymous Coward on Thursday May 29 2014, @06:29AM
Right. And then they go on to recommend fucking BitLocker, proprietary software that is quite probably backdoored by the NSA given how Microsoft seems so cosy with them. Inherent design flaws my ass.
(Score: 3, Insightful) by maxwell demon on Thursday May 29 2014, @11:15AM
If you don't trust Microsoft, you don't access your secret data under Windows. Because no matter whether you use BitLocker, TrueCrypt or anything else, as soon as you access the data under Windows, Windows will have access to it. So given that Windows and BitLocker are both made by Microsoft, there's no security difference between BitLocker under Windows and TrueCrypt under Windows. Indeed, you could argue that BitLocker under Windows is more secure, since you only have to trust Microsoft, while with TrueCrypt under Windows you have to trust both Microsoft and the TrueCrypt developers.
And no, that TrueCrypt's source code is available doesn't help you in this case, since Windows' source code isn't.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by ancientt on Thursday May 29 2014, @09:53PM
Not to you or me certainly, but it is to some people [windowsitpro.com]. I don't really know how talented their security reviewers are or what NDAs they're bound by, but it isn't fair to say that nobody has access to it.
This post brought to you by Database Barbie
(Score: 5, Informative) by coolgopher on Thursday May 29 2014, @07:13AM
I see the Wayback Machine for truecrypt.org says:
Sorry.
This URL has been excluded from the Wayback Machine.
https://web.archive.org/web/http://truecrypt.org/ [archive.org]
Sounds like more than just an abandoned project to me. I might have to go find that tinfoil hat again.
(Score: 2, Interesting) by acharax on Thursday May 29 2014, @09:17AM
Archive.org retroactively respects robots.txt, anybody could take over a domain and get it excluded from archive.org more or less on the fly.
(Score: 1) by coolgopher on Thursday May 29 2014, @09:35AM
Huh, I wasn't aware of that. That seems like a misfeature to me, but oh well. Might not need the hat after all then!
(Score: 2) by egcagrac0 on Thursday May 29 2014, @12:04PM
It seems like a misfeature, but it's the way they've decided to do takedown requests for people who left sensitive information secured only by obscurity.
(Score: 1) by iWantToKeepAnon on Thursday May 29 2014, @01:26PM
"Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy
(Score: 2) by sgleysti on Thursday May 29 2014, @03:43PM
I've done this. I think I also had to e-mail them to delete the older versions before I changed robots.txt to deny all.
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @10:40AM
i like:
https://www.archive.is/ [archive.is]
(Score: 5, Interesting) by Rune of Doom on Thursday May 29 2014, @04:39AM
We don't know enough for any firm conclusions. That said, my guess is 'warrant canary'.
http://en.wikipedia.org/wiki/Warrant_canary [wikipedia.org]
(In case anyone isn't already familiar with the term.)
(Score: 2) by Reziac on Thursday May 29 2014, @04:51AM
The tone is pretty odd, eh? You may be right.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 5, Insightful) by sgleysti on Thursday May 29 2014, @05:37AM
The encryption functionality was removed; decryption remains. This makes sense if they were required to surreptitiously weaken the encryption.
The advice given for linux users is to search for any package with the word "crypt" or "encrypt" and follow its instructions. This is strange advice from security-conscious developers.
I think the real devs did it for the following reasons:
One would expect truecrypt to attract more notice now that it is being audited. They just raised $16,000 to put it through serious auditing. This is a crazy time to nuke the project, unless they got an NSL.
(Score: 1, Funny) by Anonymous Coward on Thursday May 29 2014, @06:35AM
The audit revealed the true encryption algorithm was ROT13. Further development was deemed impossible without breaking backward compatibility.
(Score: 2) by maxwell demon on Thursday May 29 2014, @07:28AM
Those were security people. They certainly knew that these days you need triple-rot13 to be truly secure.
The problem the audit found was that the second step wasn't a decryption step, as triple-rot13 requires, but an additional encryption step.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Interesting) by threedigits on Thursday May 29 2014, @09:41AM
The "U.S." to "United States" is more than probably an artifact of changing Visual Studio versions.
You can see the same happening here, for example: https://chromium.googlesource.com/webm/webmdshow/+ /74379b419a791c5d81f1120c0f23e28d19cf03eb%5E!/ [googlesource.com]
(Score: 2) by zocalo on Thursday May 29 2014, @11:27AM
What if TrueCrypt was backdoored as the result of an NSL some time ago - say pre-v7.1a, which is when development basically stalled and could be the reason for that stall? One likely outcome of that might be a difference of opinion between the devs, ending development and culminating in a difference of opinion wherein one or more of them basically decided to blow the whistle against the wishes of the rest. If the whistleblower(s) were the coders rather than the web admin, then it's conceivable they might not have access to SourceForge but would have the code signing keys, which would explain the hacky nature of the "reveal".
UNIX? They're not even circumcised! Savages!
(Score: 2) by forsythe on Thursday May 29 2014, @01:59PM
I was actually going to mention the U.S. -> United States thing, but thought I would come off as being overly silly.
So here's something else: Towards the beginning of the diff, some options of a dialog box got changed (that didn't seem obviously related to the neutering), and the option to choose `No' was removed.
(Score: 1) by eieken on Thursday May 29 2014, @04:03PM
Secretly communicating what happened via the No seems like something to do, bothersome that I really liked TrueCrypt. :(
(Score: 5, Interesting) by c0lo on Thursday May 29 2014, @06:26AM
Technicality only: it's not a "Warrant canary" (which, if not updated, means something went wrong) but rather a "scorched-earth trap" (step on it and everything blows, nobody gets nothing, not even the attacker).
The "warrant canary" is effective because, to send the signal, you just obey an order to do nothing (I suspect, for US, there may be an amendment which protect innocent citizens against forced labor - e.g. work to introduce a backdoor against my will).
The TrueCrupt crippling is a destructive step that requires an action, there may be some "contempt of court" issues if so.
In any way, one cannot dismiss a Lavabit 2.0 scenario in progress.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 5, Interesting) by bradley13 on Thursday May 29 2014, @07:06AM
I have to agree - it seems to me that the most likely scenario is LavaBit all over again:
Truecrypt has been a hugely valuable tool for millions of people. It is cross-platform and it is absolutely easy to use. I've tried other solutions out there, and no other platform independent solution is nearly as good on the usability front - and usability is critical to security applications or else people won't bother with them...
We need Truecrypt, or an equivalent replacement...
Everyone is somebody else's weirdo.
(Score: 1) by WillR on Thursday May 29 2014, @02:11PM
There's less likelihood of the backdoor being found by an audit if it's only sent to a few entities, and that fits with other NSA activities that have come to light like intercepting and backdooring some Cisco routers in transit instead of backdooring IOS. So the TrueCrypt devs decided to play along just enough to avoid jail, then burn the key by using it to sign an update with giant flashing red "TrueCrypt is insecure!!!" warnings all over it.
(Score: 2) by keplr on Thursday May 29 2014, @04:47PM
What is stopping the government's secret, already illegal, orders from including the requirement to keep the "canary" in place. They just show up, root your servers, and tell you to act like nothing happened and do NOT take down the canary notice.
I don't respond to ACs.
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @08:20PM
The point of the canary is that if it isn't updated frequently one should assume that something is wrong.
(Score: 2, Interesting) by Anonymous Coward on Thursday May 29 2014, @04:48AM
Hmmm, stripped down site warning users of security, recommended use of proprietary software long known to be at the beck and call of various interests... High five for the red flag and ridiculous alternative methods! And after a recent report about skyrocketing encryption over chat networks. Gee, the people found out the tin hatters were RIGHT on the whole privacy thing and are looking for ways to secure themselves. It will be interesting to see the reaction when people get told they're not allowed to safeguard their own information.
If they're tricky they'll do it through a central validation committee / agency / whatever. Certified, for your protection. Maybe encryption become a thought crime and we can fully settle in to our dystopian nightmare.
** Funny side note, dystopian is apparently not a word my browser knows. Suggested change: utopian
(Score: 4, Interesting) by c0lo on Thursday May 29 2014, @10:01AM
Double-plus good spellchecker.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by Yog-Yogguth on Saturday May 31 2014, @02:37PM
Mozilla's spellchecker has a low SAT score, it doesn't even recognize "spellchecker" :P
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 2) by zim on Thursday May 29 2014, @04:57AM
Or it's not even them posting the message and it's still good but microsoft isn't. and the powers that be would like to have an easier job of it.
Conspiracy circles!
(Score: 5, Interesting) by juggs on Thursday May 29 2014, @06:46AM
At least I wish the rumour / media mill had a TILT mode like old pinball machines - it should be invoked when the amount of speculation around a particular topic exceeds the availability of genuine attributable information by a certain factor (or in this case exponential factor).
Let's bring some rationality to proceedings.
What's the history?
TrueCrypt v7.1a has been around since early / mid 2012 (to my knowledge). It provides a tool for creating encrypted volumes as files as well as plausibly deniable hidden filesystems.
What's Plausible Deniability?
In this case it's an encrypted filesystem or volume that an adversary cannot prove exists. i.e. without the correct tool to access it and the correct passphrase to decrypt it, it is indistinguishable from random guff (or noise) on a hard drive. i.e. even in bastard countries (looking at you England) where failing to provide keys to unlock an encrypted volume is reason for jail time you have a way to secure your data.
Why Have TrueCrypt's Developers Remained Anonymous - That's Got To Be Dodgy Right??!
Think about this for a while. If you were developing a tool that enabled the ability to create entire computer filesystems that could be hidden from view from even the most well funded national intelligence agencies, what would you do?
If you make yourself known you open yourself to all manner of coercion from both state and criminal actors. If you coalesce as an incorporated business / not for profit / charity then you are subject to the whims of the jurisdiction(s) that a. your corporation coalesces in b. your developers and all associated reside in.
Why The Brouhaha now?
The TrueCrypt site www.truecrypt.org has been redirected to their project pages on Sourceforge at http://sourceforge.net/projects/truecrypt/ [sourceforge.net] which carries all manner of red text warning that Truecrypt 'may' contain unfixed security issues. Along with a massively cut down release of TrueCrypt v7.2 (source and binary) that offers the ability to only decrypt volumes.
What Does It All Mean?
In true QI fashion, I have to raise the table-tennis bat labelled "Nobody Knows".
OK - So Sum This Up Rather Than Wave Your "Nobody Knows" Card Around
If I must. This is speculation all the way down from here on out.
Scenario A
----------
Devolopers of TrueCrypt have had enough and want to give it up. Regardless how mathematically correct their choice of cryptography or perfect their implementation, the ever growing processsing power to brute force encrypted volumes means that anything encrypted today only has a limited lifetime before it is revealed. This is not anything new or stunning - encryption has never been a forever solution, always a "keep stuff safe until past the point it becomes useful" solution.
Leaving the scene with a source and binary that can decrypt all previously encrypted volumes while stripping out all encryption routines is laudable. It's only a matter of time before those encryption routines become brute forceable in minimal time. Best not to offer encryption at all than offer something easily broken.
Scenario B
----------
One or more developers received a secret court order (I'll use the US-centric NSL abbreviation henceforth) to allow access to subvert TrueCrypt to be more compliant to an agency's probing. Rather than take that NSL on face value, the developer(s) in question have taken the project suicide route in whatever fashion open to them that can alert the userbase whilst keeping them safe from a life time in some hell hole gaol for contravening non-disclosure of a NSL.
Scenario C
----------
A TrueCrypt developer was sloppy and an infiltrator managed to subvert every domain associated with TrueCrypt along with code signing keys etc. etc. to be able to pull this off. Even their mailservers are bouncing all messages with recipient unknown responses.
Given the relatively long history of TrueCrypt I am inclined to A > B > C at this point.
One thing is sure, TrueCrypt has passed a point of no return with this. As the developers are anonymous, there is no way for them to reclaim their ground if this was indeed an audacious hack.
The following as points of reference:
Linux Users
LUKS and EncFS - even EncFS within LUKS devices for some layering.
Windows Users
BitLocker (version restrictions apply) if you trust MS - which you must if you run Windows.
Apple Users
Not my thing, so can't help.
(Score: 2) by juggs on Thursday May 29 2014, @06:50AM
I'm sorry that post is so ugly. It was formatted better but I fell foul of slaschcode's "Junk Characters" filter on submitting and was to too ired to redo it all so stripped out my lazy underlining.
(Score: 2) by aristarchus on Thursday May 29 2014, @07:12AM
But the take-away from your post is that Windows users are hosed. But I repeat myself.
(Score: 5, Interesting) by juggs on Thursday May 29 2014, @07:47AM
Everyone is hosed if that is your take-away. Not just Windows users, Linux users, Apple users, Android users, ChromeOS users, ~everyone~.
Run encryption atop your OS, well you have to trust the OS provider and the encryption software provider.
Run OS provided encryption - now you only have one party to trust.
If the OS is complicit then it matters not a jot what the encryption layers on top of it do, you're hosed.
The actual take-away is..... file(system) encryption, fine for preventing casual thieves who purloin your mobile devices from gaining access to your files but it's not to be relied on for defeating snooping.
But then it was never supposed to be a panacea, it does what it says on the tin - encrypts your shit while at rest (for now).
Which makes me think - say you went to the bother of one of these TrueCrypt encrypted hidden partitions then installed OS of choice on it... what prevents the OS of choice giving away whatever crown jewels? Or the underlying hardware for that matter?
Maybe this is the take-away... TrueCrypt was over a decade old and pre-dated mass Internet usage, having a deniable OS then was useful. Now not so much, it is our online footprint that betrays us.
I honestly don't know.
(Score: 2) by Yog-Yogguth on Saturday May 31 2014, @04:07PM
You are largely right. The most important thing to grasp is that TILT is the new default courtesy first and foremost of the NSA: if you are running COTS hardware (as nearly everyone does) you can not trust your hardware. This fact is not because the NSA and others have hardware implants (which they have plenty of) and it is not because they could weaken specific logic gates in whatever chips you are using (they could, it's not science fiction), nor is it because of the efforts of the NSA's TAO and their software (which is likely best of the best and amazingly brilliant), it runs deeper and is because it has become more than apparent and verified that the NSA (and any other such organization whom we might not even know about) does not have any kind of apprehension against using their unlimited clout in order to sift and/or record all data in existence using any means possible.
Sure in exceptional cases that does mean they'll use the aforementioned. It has also been shown that they will use secret courts and secret court orders and "national security letters" and any "legal device" (even if illegal) and influencing industry standards (it doesn't matter all that much whether it strengthens or weakens said standards, since it is clear that what matters to them is that they'll do it to suit whatever they think is in their own interest).
There is no reason to assume that their efforts stops there! Social hacking is always easier. If one can manipulate the foundations of academic research or industry-wide best practices or technical practical solutions it is worth far more than millions of later weaknesses. If you think you own the rabbit hole you want to make it as deep as possible: all the way down for forever, because it becomes tremendously more efficient the deeper it goes, and they have the resources to do just that.
One should by now recognize that the NSA was and will always be a "bad faith" [wikipedia.org] actor (personally this is what hurts the most). This very fact is the negative ramification of the Snowden leaks that is almost suspiciously absent from the reports on the damages caused to the US: the leaks have removed any possibility of "good faith" status for the NSA (and also the US government) and this very "good faith" status was one of the most if not the most useful property/tool/attribute they had.
Why isn't this being spelled out by the reports on the consequences of the leaks? Because they're hoping people won't notice; they're trying to avoid the Streisand effect because they would like to cling on to the incorrect "good faith" status and have as many people as possible continue to assume that they are "good faith" actors.
They can't broadcast one of the most immediate and profound damages because it would exacerbate the troubling truth: they are not the "good guys", they are evil, and they represent the doom of humanity just like the Nazis and the Commies did only with vastly improved technology.
The classic solution to the problem of a needle in a haystack is to set fire to the haystack. It won't matter that the initial motivation was to find the needles to remove and/or destroy them in order to save the hay: the solution remains the same.
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 2) by NCommander on Thursday May 29 2014, @09:24AM
Which lazy underlining?; tags should "just work" We do at least know what the underlying issue is with UTF-8 support, though we haven't managed to fix it as of yet.
Still always moving
(Score: 2) by maxwell demon on Thursday May 29 2014, @10:30AM
I guess he didn't use proper HTML tags, but used lots of "-" or "=" for "underlining", causing a repetition filter to trigger
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by NCommander on Thursday May 29 2014, @11:17AM
The entire commenting engine needs a rework. Its on the TODO list, but ENOTIME. THe problem is slashcode basically uses HTML::Validater as its comment engine, and that wasn't really meant to be used in the way we're using it. Ideally, I'd love to rewrite it to use some bbcode based system (something we've gotten requests for), and make it a bit less stupid.
Still, it does work for 95% of comments but bleh.
Still always moving
(Score: 2) by maxwell demon on Thursday May 29 2014, @11:42AM
I don't get the advantage of bbcode. So you write [ and ] instead of < and >? I don't see the big difference (except that the bbcode keys are harder to type on my QWERTZ keyboard :-)).
Now if you supported Markdown for comments, that would IMHO be a true improvement. I have no idea whether it would be more work than bbcode, though.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by NCommander on Thursday May 29 2014, @12:51PM
I feel like an ID10T for asking, but what is Markdown?
Still always moving
(Score: 4, Interesting) by maxwell demon on Thursday May 29 2014, @01:54PM
It's a way to format texts. Unlike bbcode, it doesn't rely on tags. Some of the syntax will be familiar to people previously on Usenet (e.g. quoting by starting lines with > or emphasizing by enclosing in *asterisks*), other will be familiar to people used to Mediawiki (e.g. preformatted code a la <ecode> through indention).
See https://en.wikipedia.org/wiki/Markdown [wikipedia.org] for details.
One site I know using Markdown (with a few extensions) is Stackexchange.
I seem to remember something about plans of offering SoylentNews over NNTP; in that case, the fact that some of the Markdown syntax matches the syntax traditionally used in email and Usenet posts for the same purpose (as well as Markdown text being very readable by itself) might prove useful.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by NCommander on Thursday May 29 2014, @05:38PM
SN over NNTP is a reach goal; definately something I want to do, but no idea when it might happen. I'll look more into Markdown; thanks for the link.
Still always moving
(Score: 2) by juggs on Friday May 30 2014, @02:53AM
Exactly right, I used oodles of === for underlining. It was my own laziness that caused the problem rather than a Soylent code issue.
(Score: 4, Interesting) by stormwyrm on Thursday May 29 2014, @07:55AM
Your Scenario A is complete bullshit. If it were true that TrueCrypt volumes could be brute forced, then that means that EVERYTHING can be brute forced. This is known to be false. Brute forcing 256-bit symmetric keys requires energy equivalent to that of an exploding star to do in a reasonable amount of time. Brute forcing a single 128-bit key will still require at least several hundred terawatt-hours of energy, assuming you had perfectly efficient computers capable of doing operations at the von Neumann-Landauer limit, and probably no one has those. In any case I'm pretty sure that everyone would notice if that data centre in Utah was gobbling hundreds of terawatt-hours of energy. It seems that the US consumes about 13,000 kWh of electricity per capita per year, so 100 TWh is the equivalent of a city with seven million inhabitants. It's like the energy consumption of a city almost the size of New York, and that much energy being consumed cannot go unnoticed.
I have argued on the other site why it seems unlikely that the NSA possesses some classified cryptanalytic result on AES/Rijndael (the most widely used block cipher in TrueCrypt), or that they modified the algorithm so it incorporates kleptography [wikipedia.org]. Among other arguments against the cryptanalytic breakthrough theory is that the NSA itself endorses its use by the Federal Government for classified information, when used by properly certified systems (which they've certified to contain no back doors). Against the kleptographic argument is the fact that the algorithm was designed by two Belgian cryptographers who are very well known in the academic cryptography world, and that no changes were made to the algorithm prior to it becoming a FIPS. I know from my own work being done around the time that there is no difference between Rijndael the AES candidate and AES as described in FIPS 197. I personally implemented Rijndael for an 8051-type microcontroller around 1999, and when it was announced AES in 2001, I compared FIPS 197 against Rijmen's and Daemen's spec from 1998 against which I based my code and found the two to be exactly the same. My old code also produced correct results against the known answer test vectors that are part of the standard. Kleptography seems rather unlikely given that.
Scenarios B or C are thus far more likely explanations than A in my mind.
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by juggs on Thursday May 29 2014, @08:32AM
EVERYTHING can be brute forced. That is not bullshit and it is not false.
NOTHING is impenetrable to brute force.
If you are a cryptographer you know the above to be true. Brute force implies throwing every possible solution at a problem - one will prove to be the key that unlocks the door.
I will leave aside your subsequent points about AES/Rjindael as I am not qualified to speak to their mathematical correctness nor TrueCrypt's implementation of them.
My point in Scenario A was that if TrueCrypt's developers had decided to cease work then from a security perspective it would be good practise to leave available source and binaries that can decrypt previous versions' encrypted volumes. Deleting the encryption code simply serves to prevent future adopters of the software using it to encrypt their files.
If one is walking away from supporting / developing an encryption software then it makes sense to do this. It is a delineation.
Regardless of the power / compute requirement to brute force something today, who knows what advances are around the corner. Hence why I alluded to only relying on encryption to keep your stuff safe for a finite period. It doesn't actually matter what that finite period is, but it is finite. Surely it is better to get users used to the concept rather than lull them into an encrypt now, secure forever utopia that may or may not be the case.
(Score: 2) by stormwyrm on Thursday May 29 2014, @09:04AM
So where's the supernova you can harness for the energy needed to break a 256-bit key? Or can you wait until the heat death of the universe? The theoretical minimum amount of energy based on arguments for computing using the known laws of physics requires at least that much energy to brute force a 256-bit symmetric key. Perhaps it might be feasible for a Kardashev Type 3 civilisation, but for us puny type 0 civilisations it is far beyond the realm of feasibility. As Bruce Schneier [schneier.com] put it:
Sure, anything can be brute forced. It just isn't practical to do so, which makes it practically bullshit to even try.
Numquam ponenda est pluralitas sine necessitate.
(Score: 4, Interesting) by edIII on Thursday May 29 2014, @09:27AM
That's just it though. You're missing the bigger point. Nobody is even trying to brute force anything .
At least not anymore. Once the permutations so strongly exceeded total processing power, attackers simply had no choice but to stop. They didn't even brute force Enigma the way you allude to. Take a deeper look at how Enigma was attacked. They had enough processing power during WWII to brute force Enigma *AFTER* they first reduced the keyspace with nifty mathematical analysis.
The real game, and real attack surfaces, are sophisticated analysis of the gestalt view of the ciphertext. It's a known process by which probabilities are understood, and the effective keyspace is reduced to a more viable level that can be brute forced in time periods acceptable to governments and LEO.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 4, Interesting) by edIII on Thursday May 29 2014, @09:16AM
Properly implemented OTP is mathematically proven to be immune to brute force attacks. You can literally generate ANY plaintext as long as it's the same length as the OTP ciphertext, and have absolutely no way whatsoever of knowing that you guessed the correct key. The key itself is supposed to be high entropy from preferably non-deterministically generated numbers. There is no math involved other than modular addition, and even then, it's a 1:1 relationship between each and every single bit of the plaintext and key. That's it. There is NO relationship between the 2nd bit and the millionth bit. Assuming a truly random key it's impossible to state beyond a reasonable doubt you found the key.
That's the most dangerous part of OTP. Information bias can lead you to assume that a generated plaintext from your chosen key was what you are looking for.
What do you want me to have been guilty of? Child pron? Just take any CP image bump it up against the ciphertext, obtain your key, and then claim the extra stuff was padding designed to confuse analysis. Industrial espionage? Same thing. A manifesto saying you are the one responsible for the bombs? Just as easy.
OTP is perfection as far as the method (maybe a slight addition to prevent stream attacks) is concerned. What is not perfected yet is the key exchange, and the enormously ridiculous requirement that key size be exactly the same length as the plaintext.
Otherwise, yes, OTP is specifically known to be immune toinfinite processing power.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by FatPhil on Saturday May 31 2014, @05:07PM
>
> NOTHING is impenetrable to brute force.
>
> If you are a cryptographer you know the above to be true.
Any cryptographer who thinks the above is true is not a cryptographer at all, but delusional. As is any non-cryptographer who thinks it is true.
A OTP cannot be brute forced. Provably. Mathematically. And yes, I am a mathematician. Who knows a fair bit about cryptography.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Interesting) by edIII on Thursday May 29 2014, @08:56AM
That's not entirely correct. In fact, it's much worse. You're correct about the physical limitations of classical computing though.
Bruce Schneier, Applied Cryptography, pp157-8:
This was written nearly 20 years ago. Since then, quantum cryptanalysis has become a lot more feasible. A proof of concept could be less than 10 years away from being public and in the known literature.
Schneier himself also states that the the whole point of cryptanalysis is to find shortcuts [schneier.com].
So relying on the brute force strength of 256-bit symmetric key alone is hubris. It's not simply a matter of permutations (which to be pedantic will be 1/2th of an order reduced in practice), but involves probabilities and attack surfaces beyond encrypted data at rest.
AES 256-bit has already been reduced by 7 orders below it's permutations. New attacks in the known literature go further than that. As the man said, "attacks only get better, not worse". We don't even begin to know what the NSA really has up it's sleeve. They really do employ the world's best cryptographers.
Cryptanalysis of at-rest ciphertext is only one tool. That usually involves working on the method itself. What about the RNG data being provided? It's almost *never* TRNG. Since, it isn't TRNG, that now allows the CSPRNG to be compromised. Knowing what CSPRNG was used, or likely used, could once again be used to identify valuable shortcuts shaving off the effective keyspace by several orders, or more.
Regardless of method and CSPRNG, you still have a weakness in key exchange. It matters not that your key was 256-bit. If the probabilities of the key exchange collapse that down to a 40-bit key, you're fucked.
I respect that you have implemented and coded the encryption algorithms and have experience, but I don't think it's anything but hubris to say that a 256-bit symmetric key encrypted ciphertext requires more energy than several stars to brute force. Seems reckless really.
In order to do that, you also need to show me a really impressive CSPRNG, or a massively insanely fast TRNG, *and* a truly solid and novel key exchange.
If you really wanted to impress me with bullet proof encryption you would either perfect OTP (which is not), or make quantum encryption possible. Most importantly, make it possible to have quantum encrypted data at rest and not just "cycling" in an active system. I'm betting that perfect cryptography will be solved by using quantum to provide the missing links in OTP myself.
We've been through all this before many times. People saying that a method was bullet proof, only to find a surprising and novel attack that somehow reduced the effort required by 99%. The most notable of them all *is* OTP, which is *mathematically* perfect. Except, that they found in order to be perfect in practice, you could never reuse the pad data. Damn... back to the drawing board...
(Score: 5, Interesting) by stormwyrm on Thursday May 29 2014, @09:45AM
We are discussing here the brute forcing of the key to a TrueCrypt volume. So everything else you've written about CPRNGs and key exchange isn't really germane to the discussion, as that isn't what I'm talking about. If you can find shortcuts, well, you aren't doing brute force any more right? You might as well have just spoken about the infamous $5 wrench [xkcd.com] to extract the key, and that qualifies as "brute force" only to the facetious. Quantum cryptanalysis changes Schneier's argument about brute force only a little. Apparently there's been analysis that shows that quantum mechanics can do no more than halve the effective keyspace, so a 256-bit keyspace becomes effectively 128-bit. Not a lot of help when you can do triple encryption, and you wind up at 768 bits, or effectively a 384-bit keyspace to a quantum computer.
Why do you think the NSA seems to be beefing up its ability to use exploits and put in back doors wherever they can? They cannot beat the mathematics, so they get around it by attacking the implementation rather than the mathematics. TrueCrypt may well have been on its way to becoming the sort of software that they couldn't touch in that way, and they couldn't have that.
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by edIII on Thursday May 29 2014, @10:27AM
No, we are talking about the same thing, even with the shortcuts. Brute forcing does not simply mean "trying all the keys that are possible". Brute force means that you don't possess a key, and you don't possess some mathematical insight that allows to you perform the reverse process with the same amount of effort regardless of key possession. Sufficient mathematical insight can allow you to break encryption without even finding the key. See frequency analysis among others IIRC. Whatever shortcuts are used, they only reduce effective keyspace. In the end, you are still brute forcing effective keyspaces. They just became much smaller.
CSPRNG is quite relevant to the discussion. Admittedly, key exchange is less important for TrueCrypt if we are going to strictly limit the discussion to it alone.
The CSPRNG is relevant because all encryption methods, including the ones employed by TrueCrypt, are used to provide random numbers that greatly influence key generation and routine encryption operations that generate ciphertext. If a CSPRNG is compromised this means you understand, and are able to better predict, the numbers that were used. A compromised CSPRNG is invaluable to ciphertext-only attacks, which is exactly the situation you present in TrueCrypt data at-rest. To say otherwise explicitly means you did NOT use a CSPRNG during ciphertext generation.
You are, in fact, talking about generating random numbers, following a method of encryption, and then generating ciphertext. How a CSPRNG is not critical in that undertaking is not something I can understand, or reasonably believe. The NSA *did* compromise a CSPRNG and paid very well (by their standards) to have it added to at least two different national standards for that very reason.
As for the quantum mechanics only reducing the effective keyspace by half, I cannot say anything about that but [citation needed]. I'm greatly interested in any papers that show any kind of effective limit for quantum mechanics. I don't know that is true, and by all other accounts it could allow one to slice through crypto like butter precisely because it bypasses brute force entirely in some cases.
At a very high level of abstraction, encryption is merely a simple mixing process by which it's vastly more expensive to perform de-mixing without some critical kind of knowledge. You're only arguing that a brute force defense against de-mixing without key possession is physically precluded in a very limited use case where the brute force is strictly limited to the keyspace provided by permutations alone. That's an oversimplification, and ignores whole hosts of ciphertext-only attacks, and the methods by which the keyspace for brute forcing, is reduced. Many of which focus on the random numbers used by the method, and not the method itself.
It's almost always about reducing effective keyspaces to be brute forced. That typically involves every step of the process, which by definition, includes random number generation and key exchange (where appropriate).
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 4, Interesting) by stormwyrm on Thursday May 29 2014, @01:15PM
Just had to make a few simplifying assumptions. Cryptosystems are complicated beasts, as you evidently understand as well as I do, and any vulnerability in any one area can and probably will eventually be discovered and exploited if someone cares to do so. The OP I replied to was talking about brute force attacks, and was saying how those would all eventually become feasible given advances in computing power, and speculated that that could be one reason why TrueCrypt was abandoned, just when an auditing project has gone underway that is intended to ensure that the code is solid. I didn't buy it, and considered the OP's other two speculations to be far more likely, because a simple brute force attack on the underlying block ciphers is infeasible with our current knowledge of mathematics and physics. That was all I was trying to argue, and you had to go and muddy the waters with all this talk about other components of cryptosystems that might be the source of vulnerability. :) I was not trying to argue the about the security or lack thereof of TrueCrypt as a whole.
Note that I never disputed the assertion that there might be vulnerabilities in TrueCrypt that result in its being insecure. This is actually highly probable, as the codebase is complicated and has not been fully audited as of this writing, and the true authors are anonymous. But the fact that these vulnerabilities probably exist doesn't sound to me like a reason for the maintainers of TrueCrypt to completely abandon their work the way they have, which is the real topic of the discussion. Something smells very fishy here, and what's happened to their site makes something like an NSL or its equivalent a more likely explanation.
And you were asking for a citation for why I say quantum mechanics can probably only cut the key search space in half. Here it is: Bennett C.H., Bernstein E., Brassard G., Vazirani U., The strengths and weaknesses of quantum computation. [arxiv.org] SIAM Journal on Computing 26(5): 1510-1523 (1997).
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by edIII on Thursday May 29 2014, @06:47PM
Well, I do agree that right now attempting the entire keyspace without any shortcuts is highly likely precluded by physics. That's what has provided all the momentum to work against the other components.
I just to tend to disagree with the assertions that we should rest on our laurels so to speak and concentrate all of our efforts on shoring up implementations. To be completely honest, it just smells fishy and full of hubris. I'm suspicious and skeptical by nature and any time somebody seems to be saying something is near perfect and astronomical I tend to immediately wonder why it's being said, not that it was said. I have to muddy things up :)
Now on that, we agree completely. It's far more likely IMO, that government got involved at a low level to attack implementation or other components and backdoor it, as we are talking about spying, logistics, and human behavior, not mathematics.
Thank you very much for the citation. I got some reading to do...
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 1) by Fry on Thursday May 29 2014, @09:13PM
quantum mechanics can do no more than halve the effective keyspace, so a 256-bit keyspace becomes effectively 128-bit.
2**128 != 2...
(Score: 1) by fnj on Thursday May 29 2014, @10:10PM
Unless, you measure keyspace in number of bits needed to represent all possible keys, rather than the number of all possible keys.
(Score: 2) by maxwell demon on Thursday May 29 2014, @09:24AM
I don't buy your energy limits (reversible computing can theoretically run on arbitrary low energy), but I agree on your conclusion that brute-forcing is impossible, just on different grounds:
Imagine you had a million computers where each single one is as powerful as the currently most powerful supercomputer. [top500.org] Let's further assume you can run it at peak performance. Imagine in addition that you have a super efficient algorithm which can test a single key as fast as multiplying two floats (so that the FLOPS are directly translated into Keys/s). So your million supercomputers are able to test about 5.5*10^19 keys per second.
The average number of tests you need to brute force a key (assuming you have no quantum computer, of course) is half the number of available keys. So for 128 bit keys, it's 2^127 ≈ 1.7*10^38 tests. That is, to brute force a 128 bit key, you'd need 3.1*10^18 seconds, or about 10^11 years. That's in the order of magnitude of the age of the universe.
To brute force a 256 bit key with the same setup, you'll need 2^128 times as much time, that is, more than 10^38 times the age of the universe.
OK, so there's Moore's law. Well, let's assume that it will hold indefinitely (which it certainly won't), and let's ignore that it's actually about transistor density. So if the available speed doubles every 1.5 years, this means that in 90 years, you'll be able to crack a 128 bit key in a year (but then, whatever I encrypt, I won't care about whether it is cracked in 90 years; and anyway, nobody will consider it important enough to spend a year on decrypting it), and in 192 years you will be able to crack it in a second (still assuming you have a million of the world's most capable supercomputers of the time). Of course, at that time the 256 bit key will still need a time comparable to the age of the universe. So unless you care about whether someone will read your stuff 400 years in the future, even unrealistically optimistic assumptions about computing power will keep your 256 bit encryption safe from brute-forcing.
OK, so what if we actually get a quantum computer? Well, since we are talking about brute-forcing, the algorithm of choice would be the Grover algorithm. The Grover algorithm gives a square root improvement, so it effectively halves the key length. Now the operations per second of a quantum computer may be different from a classical computer, but I think it can be assumed that it is never faster than a classical computer in that metric (after all, you can do classical computing on a quantum computer). So at worst the quantum computer would brute force the key as fast as a classical computer would for half the key length. In other words, even with quantum computers, your 256 bit key should be safe against brute-forcing for the next 200 years.
Note that all that only refers to brute-forcing; other methods to break the encryption may of course make your key unsafe much earlier (like e.g. public key encryption based on prime factorization is vulnerable to quantum computers using the Shor algorithm).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Insightful) by bradley13 on Thursday May 29 2014, @07:24AM
A recent speech to the International Association of Privacy Professionals [privacyassociation.org], by biologist Peter Watts. He called it "A Suicide Bomber's Guide to Online Privacy" [rifters.com]. His suggestion: If you can't guarantee privacy, it's better to follow a scorched earth policy and leave nothing for surveillance to find.
Seems like an appropriate speech for the times...
Everyone is somebody else's weirdo.
(Score: 2, Informative) by monkey999 on Thursday May 29 2014, @07:51PM
Bruce Schneier commented [schneier.com] on this . The talk itself is here [rifters.com](you linked to a blog post about the talk). And there are more comments on an SN journal entry [soylentnews.org]. There's more to the talk than just the scorched earth idea.
(Score: 0) by Anonymous Coward on Thursday May 29 2014, @07:38AM
If Truecrypt were free software, anybody wanting to continue developing could do so.
(Score: 5, Insightful) by maxwell demon on Thursday May 29 2014, @10:07AM
Given that to sue you for copyright infringement, the anonymous authors would have to reveal their identity, and furthermore would have to find out your identity, I guess another anonymous group taking over TrueCrypt development would be fairly secure against such lawsuits.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by tangomargarine on Thursday May 29 2014, @02:51PM
FTFY. Or am I missing something?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Friday May 30 2014, @07:05AM
You don't do much homework, do you?
(Score: 2, Interesting) by pmontra on Thursday May 29 2014, @09:38AM
Does anybody out here know the developers and ask them? That seem the only way to know what's happened.
(Score: 2) by maxwell demon on Thursday May 29 2014, @10:17AM
Assuming someone answered to your post, claimed to know the developers and told you the real reason was X, then how would you know that you can trust this message? After all, anyone could just claim this, and there's no way to check because, after all, you'd need to know the original authors to ask them whether that person posts the truth.
Not to mention that that other person, no matter whether posting the truth or not, would certainly also hide his/her identity, in order to avoid a visit from a three latter agency who would like to know the identity of the original developers.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by pmontra on Thursday May 29 2014, @10:54AM
I didn't know TrueCrypt's developers hide their identity. Whatever their reason is I don't think I'd trust a critical piece of software written by someone under disguise, not even if I can read the source code and compile it myself. It's just too easy to slip some nasty piece of code into it and get it unnoticed (some of them are called bugs and it may take years to find). Knowing the authors and their history is important for building trust. Lucky me I never used TrueCrypt.
(Score: 2) by tibman on Thursday May 29 2014, @01:46PM
I have always found that true identity is not required for trust. I completely agree with you on history though. Knowing true identity does allow you to find the person if they betray the trust. But the trust is still betrayed.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by tangomargarine on Thursday May 29 2014, @02:54PM
So basically, you're impossible to satisfy? Or would you rather that we disassembled the end binary to look for compiler backdoors?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3) by tangomargarine on Thursday May 29 2014, @02:56PM
If you can compile it yourself using GCC, either the public official build of GCC is backdoored (in which case we might as well just give up anyway), or the program actually does indeed do what the source code says.
You *do* know how programming works, don't you? The source code is *kind of* related to how the end result behaves.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2, Interesting) by pmontra on Thursday May 29 2014, @03:29PM
Auditing a non trivial piece of software is difficult. Knowing the author gives some extra hints. Given the same code base I bet we would look at TrueCrypt in a different way if it turns out that its author is
A) A well known cryptology researcher
B) Works for a big company with rumored links with a three letter agency
C) Works for a three letter agency
It might not be rational (after all the code is there for inspection) but wouldn't we?
Would we perform the audit again if it turned out to be case B, just in case we missed something (we always do)? Again and again if it were C?
(Score: 2) by tangomargarine on Thursday May 29 2014, @03:53PM
They already did an audit. It was clean.
If we knew who the devs were, it would make it much more likely that a TLA had infiltrated them. If nobody knows who they are, it's a lot harder to find them and force them to do anything.
Computer use is so fundamentally rooted in trust issues that nobody but a computing idiot savant can completely trust their own system. And even then, they'd have to write all their own software (including hardware drivers...) so there's plenty of room for just plain bugs.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by isostatic on Thursday May 29 2014, @09:01PM
They'd have to build their own hardware too, at least to a chip level. Resisters are probably safe enough, you can test them easily.
(Score: 1, Insightful) by Anonymous Coward on Thursday May 29 2014, @01:41PM
The developers could sign the message with their key.
However given the sort of message they have already released I doubt they are going to do such a thing.
(Score: 4, Insightful) by RamiK on Thursday May 29 2014, @09:45AM
To be fair, this also applied to China and Russia. Just stick to Made in EU open source encryption, communication equipment and operating systems until the ninth circuit bans NSLs. Right now, even if you trust a US based developer, he can't legally disclose backdoors and information he supplies to his government. So, just don't risk it.
compiling...
(Score: 2) by AnythingGoes on Thursday May 29 2014, @09:45PM
That was the reason why OpenBSD was developed in Canada. Back then (before 1996 or so), it was illegal to export greater than 40bit encryption outside the US, so Theo refused to use any US resources to store OpenBSD.
What is sad, is that the most tinfoil-hatted of us was finally revealed to be right!
(Score: 4, Funny) by evilviper on Thursday May 29 2014, @12:49PM
TrueCrypt Discontinued, Alien Abduction?
TrueCrypt Discontinued, Datcontinued?
TrueCrypt Discontinued, OMG Ponies?
TrueCrypt Discontinued, Somali Pirates?
TrueCrypt Discontinued, To Be Continued?
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 1) by maxwell demon on Thursday May 29 2014, @03:40PM
TrueCrypt Discontinued, received SIGINT?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by jasassin on Thursday May 29 2014, @11:36PM
Even if just for Linux. Bitlocker..... Hmmmm.... No. If they are anonymous. Why don't they tell all.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2, Interesting) by galen on Friday May 30 2014, @03:35AM
Is there any harm or increased risk in just continuing to use the version I have installed?
It does what I want it to do in the current version... does this news just mean a stop to further updates?
(Score: 1) by Anonymous Coward on Friday May 30 2014, @11:27AM
By: Anon | 05/2014
Fiction: Do you remember the scene near the end of the movie Scarface where the group of criminals conspired in an attempt to remove an individual speaking out against them before he spoke at the UN? (UN - IIRC)
Reality: Do you remember the individual who died just shortly prior to speaking out about pacemakers (and possibly other technology) and how they are vulnerable to hacker attacks?
Possibility: Sn0wd3n and/or others about to deliver a speech which mentions the useful tool TrueCrypt to a wider audience - TrueCrypt project dies.
I'm interested in the results of the complete TC code audit, but give this comparison some thought.
However, I was concerned about the project when releases ceased after 7.1a. There were steady releases up until that time and I'm curious if 7.1a was released as low hanging fruit with a backdoor and the site was allowed to operate for a few years before closing shop when the hunger for enough interesting people who downloaded/used TC was satisfied.
TrueCrypt WTF @ Bruce Schneier blogu ecrypt_wtf.html [schneier.com]
https://www.schneier.com/blog/archives/2014/05/tr
Also contains TC posts:i day_squid_bl_426.html [schneier.com]
https://www.schneier.com/blog/archives/2014/05/fr
(Score: 1) by Anonymous Coward on Sunday June 01 2014, @12:32PM
This is an alternative, compatible implementation of truecrypt. I'm surprised it is not more widely known and supported.
https://github.com/bwalex/tc-play [github.com]
Also, cryptsetup-LUKS can now mount truecrypt containers.