New effort to fully audit TrueCrypt raises $16,000+ in a few short weeks(arstechnica.com)
arstechnica.com
New effort to fully audit TrueCrypt raises $16,000+ in a few short weeks
http://arstechnica.com/security/2013/10/new-effort-to-fully-audit-truecrypt-raises-over-16000-in-a-few-short-weeks/
100 comments
> the software ... does not have code in a public repository
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 ).
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 ).
If only I could raise 16k to get 7-zip some actual source control, too...
[deleted]
Apparently TrueCrypt still has the crazy license which no one can quite figure out if it's an amateur attempt to write an open source license, or an extremely subtle trap to lure people into thinking it's an open source license so that they can later sue.
I wonder why they refuse to simply pick a standard free license. They obviously have been able to change the license a number of times, so it's not like it's a problem of having to get permission from all of the copyright holders...
It's not open source: http://opensource.org/licenses
The absence of the TrueCrypt license on the OSI-certified list itself does not signify much, since the license was AFAIK never submitted for OSI approval, but Linux distros among others have raised concerns about several versions of the license in the past, and the current one continues to be problematic IMO. Some recent discussion has been going on on the OSI license-discuss mailing list for those interested:
see http://projects.opensource.org/pipermail/license-discuss/201...
and followup messages.
(Disclaimer: am an OSI director and also am Red Hat lawyer who was involved in reviewing and rejecting the TrueCrypt license for Fedora.)
(Disclaimer: am an OSI director and also am Red Hat lawyer who was involved in reviewing and rejecting the TrueCrypt license for Fedora.)
Thanks for the info, there's a lot of old information around.
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.
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.
The assertion that TrueCrypt "has now managed to fix all the problems cited by Red Hat Legal (relayed by Tom Callaway)" is false (I'm not Tom Callaway but I am confident he would agree with me on this). The points I mention in the license-discuss posting yesterday
http://projects.opensource.org/pipermail/license-discuss/201...
were applicable (as far as I can remember) to earlier versions we looked at and as to which we raised concerns to TrueCrypt.
As I noted in that posting, TrueCrypt did change some things in response to the barrage of criticism, but not enough.
As I noted in that posting, TrueCrypt did change some things in response to the barrage of criticism, but not enough.
> There’s just one problem: no one knows who created the software.
What do they mean by this? Do we literally don't know who created Truecrypt?
What do they mean by this? Do we literally don't know who created Truecrypt?
> Do we literally don't know who created Truecrypt?
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.
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.
Same with bitcoin. Is it that good knowledge of cryptography somehow makes the author to hide it's identity?
Interesting. About anonymity, there is always the case where you don't want people knocking at your door to ask for backdoors, hidden vulnerabilities or any other requests about the software that you don't want to deal with.
One thing for sure it is based on another software.
See History (http://www.truecrypt.org/docs/version-history2)
> 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).
> 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).
People continually discover this and are shocked to learn that the authors are anonymous. This has been a known fact since at least 2005. The authors of TC are anonymous and have been for a very, very long time.
I've abandoned truecrypt for Tomb in the meantime http://www.dyne.org/software/tomb/
Let's not forget that an enormous number of people in the world still use Windows. We need a secure, reliable, and free solution for them. The only app that currently fills these requirements for Windows is TrueCrypt.
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.
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.
> We need a secure, reliable, and free solution for them. The only app that currently fills these requirements for Windows is TrueCrypt.
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.
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.
Rampant speculation that it has been back-doored by the NSA.
Also, not cross-platform.
Also, not cross-platform.
There is the truecrypt binary and truecrypt formatted encrypted volume.The format of the truecrypt volume is known and there exists open source solutions that can create and open truecrypt volumes.
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.
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.
DiskCryptor has the opposite problem: it's Windows-only.
http://diskcryptor.net/wiki/Main_Page/en
http://diskcryptor.net/wiki/Main_Page/en
Interesting I'll take a look. I need a backup system for my gf (basically a wife) to decrypt my drive in case of my passing. I had a truecrypt volume, now I switched back to OSX encryption.
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.
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.
Here's a 58 character phrase:
You always find something in the very last place you look.
[deleted]
I would have at least 1-2 slang/leet-speak words in there to counter dictionary attacks.
Actually, as the Ars technica articles have shown, it takes much more than that to protect from a dictionary attack with the speed that passwords can be tried now.
http://arstechnica.com/security/2013/10/how-the-bible-and-yo...
http://arstechnica.com/security/2013/10/how-the-bible-and-yo...
A 58 character passphrase defeats all demonstrated examples in that article.
But the point is being missed - two months? "I taught my wife in two months the passphrase"? Completely moronic.
But the point is being missed - two months? "I taught my wife in two months the passphrase"? Completely moronic.
58 characters made up of English words with spaces between, especially if the words form a sentence, is much less secure than 58 random characters. Of course, good luck memorising 58 random characters.
No the point isn't being missed. How easy that phrase would be to crack is debatable and I don't know the correct answer, but let's assume that it is easy, you might need to make it more complicated. If this is the case, then the fact that a simple easy-to-crack phrase is easy to learn is irrelevant, like saying "it's quick to learn every word of French you'll ever need to speak - bonjour, oui, non". On the flip side, if you're right that the phrase is secure enough, then your argument is valid that it should be fairly quick to memorise. But the question of whether that phrase is good enough is entirely relevant and not missing the point.
(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.)
(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.)
The specific phrase is or isn't easily crackable, that's as debatable as anything. It's not relevant to what I've been saying at all. What's not debatable is the fact that this dude "taught it to his wife" in a multi-month span. That's pants on head stupid. Combine that with "basically a wife", and the dehumanization/patronization was enough to piss me off, cryptographic overkill aside. Maybe that's just me. Whatever.
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?
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?
You're still debating whether or not it's easily crackable.
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.
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.
Yes, if what you ask us to imagine were what happened, then you'd be right. It didn't, however, so you are not.
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.
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.
Actually, the issue with that phrase is that it's a common one, likely to be found on the web or in books - It's not just a collection of random words. You can't just consider the length of the passphrase.
Because if you don't use a passphrase for a long time you tend to forget it, especially if there are minor abnormalities in the phrase to defeat the dictionary attacks.
And the phrase isn't in english, but in russian translit.
Kinda like this: PustVsegdaBudetSolnze$PustVsegdaBuduYa
Good luck cracking it.
And the phrase isn't in english, but in russian translit.
Kinda like this: PustVsegdaBudetSolnze$PustVsegdaBuduYa
Good luck cracking it.
A dictionary attack? Are you kidding me?
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.
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.
A phrase like that is very easy to crack actually. People have been cracking brain wallets in the Bitcoin world (think storing all your money behind a passphrase that anybody can access, madness!) with greater complexity than that. From the person in questions posts, they're trawling wikipedia, quote databases, movie scripts, anything you can imagine to find phrases that people might use for passwords. It seems to work too, judging by the number of times I've encountered this person saying "hey, that's me, I stole those!".
The fact that there's google results for that phrase means it's a useless passphrase.
The fact that there's google results for that phrase means it's a useless passphrase.
Indeed, sure it's long(ish) but it's trivialized by the commonality of the words it contains.
It's simply not, due to the fact that you don't know it's a passphrase. You know nothing about the password, you will never get to trying it.
You underestimate people. More often than not people will use a quote like the example in the parents post did. In a world of custom FPGA devices to crack passwords, it wouldn't take long.
Okay, than show me. Show me the algorithm that'd crack the password I just came up with.
A forum scraper bot comes across this page:
http://www.banjohangout.org/archive/251990/14
"You always find something in the very last place you look."
Bamn.
http://www.banjohangout.org/archive/251990/14
"You always find something in the very last place you look."
Bamn.
[deleted]
There was an article on ArsTechnica just a few days ago about this type of passwords:
http://arstechnica.com/security/2013/10/how-the-bible-and-yo...
Obligatory xkcd: http://xkcd.com/936/
That is one of my least favorite xkcd comics. It is very misleading.
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.
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.
You have completely missed the point of the comic, which is that if you choose 4 common English words at random, the entropy is surprisingly high. It isn't based on "human readable strings" at all.
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.
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.
Except when people create phrases like that they aren't choosing random words from a dictionary, they're most likely choosing words from their own vocabulary which will be significantly less than 100k words. Additionally the distribution is not uniform, reducing entropy even further.
Every password require that the user choose randomly. Words, letters, numbers, pixels on a screen... All require randomness in choosing.
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.
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.
I don't see what's wrong with my argument that choosing a pass phrase will have less entropy...
Does less entropy not mean less secure? Or am I just reasoning about the entropy all wrong?
Does less entropy not mean less secure? Or am I just reasoning about the entropy all wrong?
Less entropy means less secure. However the method in the comic is not pick a passphrase. It is pick 4 random words(hopefully with the help of a computer with a good source of randomness, so they are really random). This is because phrases have semantic meaning and reduced entropy. Also people tend to pick phrases that are common enough to be found on the internet somewhere like movie quotes, book quotes and thus are likely to be in an attackers dictionary. So four random words not a phrase has better entropy than a passphrase, and is less likely to appear in a dictionary attack than a phrase.
Their own vocabulary may contain words that are not in the dictionary, such as slang, intentional or accidental misspellings, etc.
Yes this is true. This is why password crackers will scrape twitter/facebook/whatever for modern slang, common mispellings, neolgisms, etc for their word lists.
I don't think it's particularly misleading; if you look carefully, he's assigning 11 bits of entropy for each word in the passphrase, in other words, choosing from a list of 2048 common words only.
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.
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.
That's not true. Given a dictionary of 2048 words that the attacker has complete knowledge about, picking any 4 random words will always give you 44 bits of entropy.
2048^4 = 17592186044416
2^44 = 17592186044416Yes but grammatically correct sequences of words have much less entropy than that. I guess much much less.
As a rule of thumb, English text has about one bit per character of entropy. [0, 1] Since we're going with averages, let's say 5 letters + a space for each word. So you need a 7- or 8-word sentence, with normal capitalization and punctuation, to get 42 bits of entropy. And of course it shouldn't be a well-known phrase like "I've got a bad feeling about this!"
[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
[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
Thanks, great info.
> as we've restricted the search space to a multiple of the number of common English words
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.
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.
> If the attackers knows that your password is constructed in this fashion
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.
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.
[deleted]
It's a known maxim, that's probably included in many sentence dictionaries.
Show me.
http://www.chessgames.com/~AylerKupp?kpage=35
Crackers are using phrases from literature and the bible. Trawling the rest of the internet is not far behind.
Crackers are using phrases from literature and the bible. Trawling the rest of the internet is not far behind.
I responded to this kind of argument here:
https://news.ycombinator.com/item?id=6558509
https://news.ycombinator.com/item?id=6558509
Except now that'll be the first place I'll look :D
Few months? How about "anAardvarkAndAHippoAreNeverFriends@" easy to remember and almost impossible to brake. Worst case, lets say that attacker actually knows that the password is 6 words with a special character at the end. Lets further assume that the attacker knows that the words are not overly complicated, say from a subset of 5,000, and the special character is one of the 10 that's easy to type on the keyboard. Even than, at the speed of 10 million passwords per second it would take 500 million years (just about) to crack that one, and no need for months of memorization.
Not true, see this article for more information. http://arstechnica.com/security/2013/10/how-the-bible-and-yo...
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.
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 [1] replaced TrueCrypt for me.
> "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
https://aur.archlinux.org/packages/zulucrypt/
https://aur.archlinux.org/packages/python2-pbp
> "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
https://aur.archlinux.org/packages/zulucrypt/
https://aur.archlinux.org/packages/python2-pbp
Personally, I have trouble trusting people who write thngs like "Windowz" and "Winslows" on their product home page.
I hope they've taken a snapshot of the software before announcing the crowdfunding campaign. If there has been any update since then, and it had any backdoor, it may have already been removed.
The best thing someone could do for TrueCrypt security is to very publicly release a version with a backdoor, easily exploited, and difficult to detect, for anyone else to distribute. By making that a real threat, users will end up checking their source/compilation/results, protecting them against the same threat from real attackers.
That might be a cute object lesson in good security practice for the security cognoscenti, but the overwhelming majority of potential users in the world will just throw up their hands in despair and say that we can trust anything and privacy is impossible.
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.
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.
(Not saying auditing truecrypt is bad; I'll probably donate some $ once I get back to the US)
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...)
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...)
So um how do we know that none of the people conducting this audit are secretly working for NSA?
Somewhat james bond-y idea but you get the point.
Somewhat james bond-y idea but you get the point.
This is the new Slashdot "First Post", isn't it?
It's more like the new "imagine a beowulf cluster of these" meme, a comment generic enough that can fit most stories while contributing nothing to the discussion.
They could have settled for "I, for one, welcome our new NSA overlords".
They could have settled for "I, for one, welcome our new NSA overlords".
What?
Kids these days.
My god, we are old, Thomas. This is what most graybeards must feel like.
Hmm?
How do we know you're not working for the NSA to undermine the credibility of the audit?
How do we know you're not working for the NSA to undermine the undermining of the credibility of the audit? :P
That's exactly the point
In theory, it shouldn't matter. A public audit is public, so the work can be scrutinized by anyone.
Hate to break it to you and others; but there is a high degree of likelihood that it is actually even an NSA funded operation, not to mention having assets that add backdoors.
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.
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.
Here's the thing...if any government organization actually goes through a truecrypt backdoor or flaw, the odds are very good that the news will get out. Yeah, if they seize a computer, crack it and never provide the unencrypted information to a court or other public forum (and somehow shut-up the perpetrator), they could keep it secret. But what's the point?
Your claim is that use of decrypted information would reveal the backdoor.
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.
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.
I'm trying to imagine a parallel circumstance and I cannot. Most governments would not use truecrypt, but rather something they have control of themselves. The people using truecrypt illicitly are ordinary criminals: Gangsters, child pornographers, terrorists (maybe), money-launderers, drug dealers, etc. The information revealed by a crack is not something that can be used in the manner of that by espionage. (ie, it won't tell us that Rommel will be approaching Cairo at such-and-such a date.) Information via espionage can be filtered down as if it were from other intelligence sources, or even guessing. And so the exploit can be concealed as with Ultra.
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.
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.
Precisely the circumstances you're trying to imagine is being done by the DEA using information from NSA intercepts:
"(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...
"(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...
How does that apply to TrueCrypt? Is the claim that TrueCrypt is secretly siphoning off data and feeding it to the NSA? Or is the claim that the NSA sent a dude to sneak into my house, image my hard drive, and then decrypt it?
If you sync your TrueCrypt volume to Dropbox or other cloud storage (an excellent use case for TrueCrypt, by the way), a backdoor could be exploited by whoever has access to the Internet traffic or the servers.
> 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.
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.
Read about "parallel construction" to get an idea, it was on news few months ago..
http://www.reuters.com/article/2013/08/05/us-dea-sod-idUSBRE...
Till then time, we will and we should doubt it.