New effort to fully audit TrueCrypt raises $16,000+ in a few short weeks
arstechnica.com
arstechnica.com
Till then time, we will and we should doubt it.
Yes, TrueCrypt should use a revision control system like Git or SVN. However, your comment can be misinterpreted as saying that TrueCrypt doesn't release source code at all.
It's worth mentioning that the full source code is available ( here: http://www.truecrypt.org/downloads2 ).
(Disclaimer: am an OSI director and also am Red Hat lawyer who was involved in reviewing and rejecting the TrueCrypt license for Fedora.)
The Wikipedia page seems to indicate you (as Red Hat) have no further objections: https://en.wikipedia.org/wiki/TrueCrypt#Licensing_and_Open_S... - I guess this is wrong.
and the OSI minutes page seems to indicate the TrueCrypt license was going to be rejected (maybe I'm misreading this): http://opensource.org/minutes20061213 - but this is from 2006.
As I noted in that posting, TrueCrypt did change some things in response to the barrage of criticism, but not enough.
What do they mean by this? Do we literally don't know who created Truecrypt?
> 1.0
> February 2, 2004
> Note: TrueCrypt 1.0 is based on E4M (Encryption for the > Masses). Therefore, the following list contains > differences between E4M 2.02a and TrueCrypt 1.0 (minor > differences have been omitted).
Yes, that's right. (The very earliest version was based on work 13 years ago by Paul Le Roux, but it's undergone enormous work since then by some person or group.)
TrueCrypt is a popular, carefully designed, well written, well maintained, highly stable and non-trivial application, but its authors are completely unknown. The open source world does have some quiet humble people, but it seems surprising that the authors want to remain totally anonymous for developing a legitimate and well-respected product.
It's basically a drive (in a safe deposit box) with all of my stuff there, also with a copy of my lastpass passwords unencrypted. My gf knows our phrase, 50 characters no less. Took me few months to teach her it.
You always find something in the very last place you look.
http://arstechnica.com/security/2013/10/how-the-bible-and-yo...
But the point is being missed - two months? "I taught my wife in two months the passphrase"? Completely moronic.
(You could still make the point that two months is two long for any phrase, I'm sure, but without knowing how much more complicated it is than your example, and without knowing how different people manage learning things, that's hard to say.)
But let's pretend we're talking about complication for a moment (a much more interesting conversation to all of us anyway), and then let's realize that this very sentence probably would take about a minute to memorize, and would be completely uncrackable.
You're forgetting password cracking 101 - it gets a lot harder, even if the word/phrase only gets a little longer, or a little different. Sly dogs instead of lazy dogs, a hand in the bush is worth two in the bird, sally smells sea shores by the she shell, every fine boy does good; what do you want from me? You'd never crack any of those, and we both know it. Why? You'd never try them. You just wouldn't. Show me the algorithm that'd come up with, "No champions, play like excuses!" Only 32 characters, should be trivial. Right?
Let's imagine the phrase you were saying needs to be remembered is simply "password", whereas a phrase good enough to not be cracked actually needs to be 400 characters long and include punctuation and numbers. In that scenario, you would be thinking "should take 10 seconds to memorise", whereas realistically it takes much longer.
That shows that the difficulty of phrase is of course relevant to how long it might take to learn, and the fact that other people have been arguing with you over how difficult the phrase needs to be shows that it is debatable.
So maybe you're right that your example phrase is fine, but if his wife learned a much more complicated phrase then it could well take longer to remember.
The difficulty of the phrase is not relevant to how long it might take to learn, because of how cryptography works. That is, a 60 character phrase is much harder to crack than a 58 character phrase. So, the difference between "password" and "this is the password I'm going to use from now until the end of eternity" is cryptographically large, but trivial, memorization wise. So while the difficulty of the phrase to crack just jumped into "not gonna happen" land, the difficulty of the memorization of the phrase moved from instantaneous to 5-10 minutes.
If his wife learned a much more cryptographically complicated phrase it still would not have taken her longer to remember, making the specific phrase completely irrelevant. Two months is laughable, "taught it to my gf" is doubly laughable, and "gf (basically a wife)" is off the laughable charts.
And the phrase isn't in english, but in russian translit.
Kinda like this: PustVsegdaBudetSolnze$PustVsegdaBuduYa
Good luck cracking it.
You don't know it's alphabetic, you don't know it's an actual English phrase, you don't know how long it is, you don't basically know jack shit to be able to effectively use a dictionary attack against a password like that. You don't know it's a passphrase, basically.
The fact that there's google results for that phrase means it's a useless passphrase.
http://www.banjohangout.org/archive/251990/14
"You always find something in the very last place you look."
Bamn.
Now show me the actual algorithm that generated the passphrase without knowing the cleartext beforehand.
If the attackers knows that your password is constructed in this fashion, then it is trivial to track the password, as we've restricted the search space to a multiple of the number of common English words. The entropy argument only makes sense if the human readable strings are just as likely to be chosen as passwords as other random strings, which is not at all the case.
For example, my /usr/share/dict/american-english contains just shy of 100,000 words. A random word chosen from that set has 16.6 bits of entropy, and four randomly chosen words has over 66 bits of entropy. If anything, XKCD's comic is understating the entropy involved.
This is why some websites assign passwords to users and do not allow users to pick their own custom passwords. The only safe passwords are those generated by machines.
This does not mean that picking words to form a pass-phrase is less secure than picking letters to form a password.
Does less entropy not mean less secure? Or am I just reasoning about the entropy all wrong?
Then all bets are off, but they don't, so we're sorted.
Mind you, my /usr/share/dict has ~ 100,000 words in it. 100,000 5 is around the same order of magnitude as 62 12, which is the number of 12 character passwords of upper and lower letters + digits.
This is probably quite close to what a brute force passphrase cracking software would do as well, and he's not even adding bits for common alterations, such as capitalisation of first letter(s), spaces between words, common substitutions, etc. So the 44 bits estimate is for a software matching exactly this pattern, using exactly this common English dictionary.
Also, I suspect throwing in a single word from another language would greatly increase overall strength, especially if it's an uncommon word.
2048^4 = 17592186044416
2^44 = 17592186044416[0] The original http://www.princeton.edu/~wbialek/rome/refs/shannon_51.pdf
[1] and some evidence that it's still correct http://en.wikipedia.org/wiki/Hutter_Prize
Diceware uses a set of 7776 words. You select words from the list using 5 dice. 5 words, picked using 5 rolls of the set of 5 dice, gives you about 64 bits of entropy.
> A five-word Diceware passphrase has an entropy of at least 64.6 bits; six words have 77.5 bits, seven words 90.4 bits, eight words 103 bits
Because our attacker knows that we've used Diceware, and knows what diceware wordlist we used, and knows that we've used a 5 word passphrase, there are 7776^5 phrases to try. That's 28,430,288,029,929,701,376.
http://world.std.com/~reinhold/dicewarefaq.html
I'd be interested if you think Diceware is broken.
Crackers are using phrases from literature and the bible. Trawling the rest of the internet is not far behind.
Passphrases are not more secure then regular passwords by default, the problem is that a lot of people use phrases that follow simple grammar. Capital first letters of each word, a sentence that is actually valid and no spelling mistakes make it a lot easier to crack then 50 random characters (or 20 random characters). Passphrases that work are random sequences of words that have spelling mistakes, random capitalization, aren't found in any book/song/poem and preferably mix several languages. The famous "correct horse battery staple" is better then your example, I have memorized 20 random words from 3 languages and use those words in some combination in all my passwords.
> "zuluCrypt is a front end to cryptsetup and tcplay. It makes it easy to manage LUKS,PLAIN and TRUECRYPT encrypted volumes through a GUI and a simpler to use CLI interface."
If you can handle experimental CLI-driven software, pbp [2] is interesting.
> "PBP is a simple python wrapper and a command line interface around libsodium, to provide basic functionality resembling PGP. It uses scrypt for a KDF and a much simpler packet format, which should be much harder to fingerprint, pbp also provides an experimental forward secrecy mode and a multi-party DH mode."
[1] https://code.google.com/p/zulucrypt/
[2] https://github.com/stef/pbp
That's why I think it's a great idea to do a security audit of TrueCrypt since that's the best available solution for a big segment of the world's population.
All it will take to have alternatives in windows is for windows based block device encryption applications to pick up the format.It is surprising it hasnt happened yet and this drive is completely ignoring this line of thinking.
What's wrong with BitLocker?
EDIT: Keep in mind we are just talking about Windows solutions here. And if Windows is backdoored, it is not going to make much difference if BitLocker is also backdoored by the same agency.
Also, not cross-platform.
If we want ordinary people to benefit from TrueCrypt, a better idea would be to find secure ways of distributing signed and verified copies of the binary. I'm saying binary because most users in the world will be ordinary Windows and Mac users, not software developers. Most people in the world cannot compile from source.
Also, as a first step, we need to do this security audit of TrueCrypt.
This problem already exists, and is actually something Mac App Store, iOS/iTunes store, and Google Play do a pretty good job of solving; I assume there are some similar solutions for Windows (I don't really know the windows consumer software distribution space).
The extensions improvements in Chrome/Firefox (and I guess other browsers, but I don't follow them) also are a great step forward toward this.
Ubuntu/Debian do a pretty good job of locking down main repositories, too. It's really just a matter of training users that downloading random code from random URLs is risky.
Once locked-down distribution hits critical mass, you can probably get away with making it even more difficult and obvious-to-the-user-he-is-doing-something-risky in "sideloading" applications. You can also have corp/org security policies which prohibit this kind of thing.
Obviously there are sacrifices for this -- it becomes possible for a platform owner to restrict availability of apps based on non-security considerations, like being anti-porn (Apple), complying with the union of laws of all countries, etc. Or just outright commercial anti-competitiveness (again, mostly Apple...)
Somewhat james bond-y idea but you get the point.
They could have settled for "I, for one, welcome our new NSA overlords".
How do you prevent and deflect efforts to develop a truely secure solution? ...You provide a solution that works and looks shiny and nice and defuses any kind of efforts. It's jiujitsu.
I'll offer the Enigma cipher as a counterexample:
The British were regularly reading and acting upon encrypted German messages in 1940. It may have changed the course of World War II! The Germans did not learn that the British had broken the code despite German ships being sunk based on the Enigma crack. In fact, nobody in the public knew until 1974. ( ref: http://en.wikipedia.org/wiki/Ultra#Post-war_disclosures )
A government organization could make good use of a TrueCrypt backdoor without it ever being revealed in court or a public forum. They can act on the information using a pretext for example.
But to use truecrypt against the people who are actually using it for crime you would almost certainly have to reveal the exploit publicly in a court.
That's definitely not true. Often police and prosecutors will go to great lengths to hide a wiretap from the courts, especially if direct evidence didn't come from it. There have also been many cases where wiretaps haven't been disclosed in court because there may be on-going related operations that require the same surveillance. You don't want to tip people off. I don't see why any potential exploit wouldn't be the same.
Here's an example: say you're investigating some organised crime. You learn from a wiretap that the next day one of your informants is going to be killed. You clearly want to prevent the latter without disclosing you've got an active wiretap.
"(Reuters) - A secretive U.S. Drug Enforcement Administration unit is funnelling information from intelligence intercepts, wiretaps, informants and a massive database of telephone records to authorities across the nation to help them launch criminal investigations of Americans. Although these cases rarely involve national security issues, documents reviewed by Reuters show that law enforcement agents have been directed to conceal how such investigations truly begin - not only from defence lawyers but also sometimes from prosecutors and judges. The undated documents show that federal agents are trained to recreate the investigative trail to effectively cover up where the information originated."
I recommend the whole article here:
http://uk.reuters.com/article/2013/08/05/uk-dea-sod-idUKBRE9...