TrueCrypt audit project founder: 'We've set our sights high' A TrueCrypt audit project has uncovered a well of technical support with its plans to publicly audit the widely used disk and file encryption utility for the first time. TrueCrypt is a widely used utility that encrypts and decrypts entire drives, partitions or files within a virtual disk. The tool can also hide volumes of data …
Being involved in this stuff, a little, I saw the writing on the wall a long time ago. I have pretty much zero trust in anything that I cannot compile from sources and not so much even then unless I use my own compiled version of the compiler. Even so, I do not fool myself that I am immune.
The forces of evil such as the NSA have their hooks *very* deep in this stuff. Even people who are experts make mistakes that allow a breach. Non-experts are mostly at the mercy of whatever entity supplies their security software.
I have, for many years, wondered why the following gets glossed over as if it is unimportant:
1) A perfect one-time pad gives perfect and unbreakable security.
2) Key sizes are ridiculously short for no reason. They should be in MB, not KB for anything important
3) PKI is badly broken, Key sizes are too small, algorithms are suspect, there are no trustworthy CAs, etc, etc.
4) The weakest link in even well designed systems is the entropy source used for the generation of keys, nonces, salts, etc.
There are all kinds of other weaknesses as well. Prime among the weaknesses we have is outside of the technology. We need air-tight, iron-clad legislation that removes rewards as much as possible and creates genuine penalties for any breach of privacy.
The fact that our security infrastructure is so byzantine and has so many obvious weaknesses and the fact that these are not addressed make me entirely suspicious of the community producing this stuff.
1) Key sizes should be enormous -- as much as the traffic can bear and they should scale with capacity.
2) There should be no dependence on one single hashing routine or cipher in a given message.
3) Nonces should be everywhere there is some 'edge' that can be peeled back.
4) Salts should exist through the system.
5) A vanilla part of anything pretending to be secure should be a portion that uses a true one-time pad.
6) All aspects of the system should be distributed, taking control entirely away from any single party or cabal.
Instead of IPv6, we should have had an open-ended addressing system such that not knowing the address of something makes it impossible to find it.
The main quick fix that is a sure thing slam-dunk is to alter legislation to make it dangerous and fruitless to intercept and inspect other people's data and to make it illegal to collect even encrypted data without a warrant.
Criminals use all kinds of things like automobiles and roads, drinking water, electricity, etc. Criminalizing those things would reduce crime, but at a cost that is unacceptable. If we killed everybody in a nuclear holocaust that would stop pedophiles in their tracks but that is obviously not a solution. Similarly, our communications networks and our right to be secure in our privacy is *not* negotiable. Whether it stops crime or not, it is a price we cannot pay.
So err...the question has to be asked of such folks that feel they have to keep all their stuff 'secret' -
What exactly are you up to that might make the NSA etc. even vaguely interested in what you do?
Most intrigued.
In reality I'm sure you are just as boring and irrelevant to the NSA etc. as the rest of us. Sorry but the NSA really isn't hanging on your every word.
"In reality I'm sure you are just as boring and irrelevant to the NSA etc. as the rest of us. Sorry but the NSA really isn't hanging on your every word."
I don't care whether they are "hanging on my every word" or not. They have no fucking right to my communication without my consent / a judicial warrant ,period.
Give 1, 700 000 eyes (and counting) access to my private communications? Awil Omnearse.
I'm sure they're not, and if using encryption and VPns etc. means they might think I've something to hide fuck 'em. Let them waste thousands of computing hours trying to decrypt the mail I sent to my friends detailing the location of our upcoming piss up. I'll fuck them up and waste their time just because I can.
As for the weakest link in any encryption, isn't it the human factor, which you really can't do much about? Isn't that why social engineering and the rubber hose are so effective?
As for computationally-expensive algorithms, this poses a challenge. What if you must be secure BUT you also have limited resources (such as a weak embedded system that nonetheless can't be replaced or the need to be able to do LOTS of them at a time so even a top-end CPU get bogged down), meaning you MUST be computationally cheap as well? Would this be considered intractable? And if so, what happens when forced into such a situation with no room to improve?
quote: "I'm sure they're not, and if using encryption and VPns etc. means they might think I've something to hide fuck 'em. Let them waste thousands of computing hours trying to decrypt the mail I sent to my friends detailing the location of our upcoming piss up. I'll fuck them up and waste their time just because I can."
While I completely agree with the sentiment, that only works in the US; here in the UK we are required by law to reveal the keys / decrypt the content for the executive branch when they demand it. Failure to do so is a specific offense which carries a custodial sentence (up to 24 months if memory serves).
So you can have a properly perfect OTP with astronomical key strength, but your data is only as secure as your willingness to go to prison :(
Note: I've not seen anything confirming whether a subsequent decryption request, once you have served your time, counts as double jeopardy or a seperate, new offense. I would suspect that the powers that be would prefer it to be counted as a new offense, with a new sentence each time you refuse... ^^;
But wouldn't they have to prove first that the data they want you to decrypt is, in fact, encrypted data rather than just a bunch of gobbledygook that resulted from testing a random number stream?
Indeed, what if the block of data being asked about REALLY IS just a bunch of random data without any decryptable value?
"1) A perfect one-time pad gives perfect and unbreakable security."
And therein lies the problem: the word "perfect". OTP REQUIRES perfection to be unbrekable, and this is an imperfect universe, imperfect people, and imperfect circumstances (suppose you're forced into a tech-free environment--then space is at an absolute premium). Plus because OTP encryption is symmetric, there's the matter of synchronizing OTP's, epsecially between people other than close acquaintances (remember, key exchange between "strangers" is one of the not-really-solved problems of encryption). There's a reason asymmetric encryption has its uses, and until someone comes up with the asymmetric version of OTP, it will not be an ideal or even practical solution for most.
"2) Key sizes are ridiculously short for no reason. They should be in MB, not KB for anything important"
Beyond a certain size, key exchange becomes more of an overhead than the material itself to be transmitted. Plus, consider the possibility of key rotation which means the key changes periodically, and you don't want to waste bandwidth and time transmitting large new keys. Plus there may be situations where the bandwidth is limited or the material to be transmitted small.
Finally, for a state adversary, key size may simply cause them to change tactics and focus more on pwning where they can obtain the key from the inside (in which case size is irrelevant--they could retrieve a 10Mbit key as easily as a 10kbit one).
"5) A vanilla part of anything pretending to be secure should be a portion that uses a true one-time pad."
Again, OTP is useless for an asymmetric environment. How can use use an OTP if Alice and Bob have never met or do not meet on a regular enough basis to synchronize the pad?
"6) All aspects of the system should be distributed, taking control entirely away from any single party or cabal."
This one concerns me, because what if a malcontent uses the distribution system to jump from one party to another? Distributing the system means you need to secure the distribution system as well, which means more potential points of failure, if you ask me. IMO, theoretically, it's ALWAYS possible to subvert a trust system (look at Bitcoin, El Reg covered a possible usurpation scheme); it goes to human instinct, which you cannot factor out as long as humans are involved. Just because it's painstaking to undo all the steps doesn't mean there's someone (like MiniLuv) that is determined enough to subvert EVERYTHING.
Re: imperfect OTP is imperfect...
Just because you could drink poison does not mean you will or you should drink it. To the extent that you fall short, and you always will, the OTP will be imperfect to that extent. Everything else suffers from that defect *plus* their other defects. With a target model of a one time pad, you have a clear goal whose endpoint will be as strong as you can make the use of keys and key exchange. Anything else and you inherit an extra weakness.
I do not want to trivialize the problem of generating the OTPs and exchanging them. Were the secret very valuable, I would be inclined to go that way, despite the difficulty. However, I am of the opinion that any system at all should have at least a portion that is protected by such a mechanism. We really cannot know for sure what weaknesses exist in other systems. The problem of the OTP is at least a clean one and your security is proportional to however close you come to that idea.
You know for a fact that other systems are weaker, but you can not be sure how much. In some cases, something that looks very strong can in fact be trivial to break if you know how.
Re: "Beyond a certain size, key exchange becomes more of an overhead than the material itself to be transmitted."
Keysize has been historically contained to something that it is theoretically feasible to break with just a small advantage. That would make anyone with even modest knowledge of this area wonder. The difference between a 16 kilobyte key and a 16 byte key is trivial as far as transmission and exchange, especially if just setting up. Certainly you could go to 8,192 bit keys easily enough and the difference between that and a 1024 bit key should be enormous under attack.
Re: "you don't want to waste bandwidth and time transmitting large new keys. "
Maybe you don't. I am not so sure about myself. I would rather transmit large new keys and have security rather than dispense with security.
Re: "Plus there may be situations where the bandwidth is limited or the material to be transmitted small."
This is one of the arguments that leaves me scratching my head. Why would we design a *limitation* into our system to satisfy the systems with the very least amount of power? Our protocols should have the two ends negotiate security as strong as they can comfortably manage, not as weak as necessary to support any device.
Re: "for a state adversary, key size may simply cause them to change tactics and focus more on pwning where"
Uh, that is a point in its favor, not against it. Yes, if we can guarantee that we can make one part of the wall so high they don't even try, that is a good thing. They are always going to go for the weakest spot in your defenses. That is no argument for creating weak defenses.
[As an aside apropos of the above, one of my design points is to have nested decoy messages that cause the attacker to waste resources investigating blind alleys.]
Re: "they could retrieve a 10Mbit key as easily as a 10kbit one"
I have commented elsewhere at the Reg that for stuff that is *really* important I would deal in key sizes running to many gigabytes or even terabytes. If I am designing against a well funded state attacker, I would require resources both sides so enormous that an attacker has trouble getting the resources to attack. In fact, if you use 'data pigs' with terabyte disks to transport enormous keys in meatspace you can be virtually guaranteed that they cannot be stolen without your knowledge and that they will be extremely challenging to intercept and analyze online.
The biggest challenge in overcoming weaknesses is recognizing them at all. You are pointing to places where poor design points could weaken your system. The response to that should not be to throw up your hands and say it is hopeless. The response should be to close that avenue of attack.
The correct response to 'our algorithm is too intense for our slow machines' is not that we should weaken it. It is that we should beef up our machines.
Re: "Again, OTP is useless for an asymmetric environment. How can use use an OTP if Alice and Bob have never met or do not meet on a regular enough basis to synchronize the pad?"
I repudiate the notion that something with a known security issue should be used in all cases when it is not necessary in all cases. Perhaps we have a situation where we simply must do that, but I would not make a fault that is a necessary evil in one case apply to cases where it is not necessary.
I am attempting to protect against any breach. The protection against a MIM attack will require a third party somehow. If you have a third party that you can trust and you both have keys you share, the third party does not require Asymmetric encryption to issue you both a session key that by virtue of being issued from the party you both trust verifies the other party.
To the extent that I must have asymmetric encryption I would use three different asymmetric methods to exchange and sign keys. It is bizarre to me that the notion of applying multiple locks to things gets such short shrift. Requiring that they steal three different keys and/or use three different attacks to get your message is *worst case* just as strong as one.
Re: [Criticisms of distributed control]
Distributing trust can admittedly become complex. However, that does not invalidate its utility and it is certainly possible to overcome any problems. Wikipedia is a testament to the fact that even something naked to attack can be reasonably secured for a given purpose.
Re: "what if a malcontent uses the distribution system"
Here is where we diverge completely. One of the purposes of distributing the system is to make it possible for malcontents to communicate securely. Today's heroes were yesterdays malcontents. We need to make it possible for the good guys to move about.
Re: "theoretically, it's ALWAYS possible to subvert a trust system"
It is *possible* that Russell's teapot exists. That does not make it probable let alone something we should rely upon.
<blockquote>
1) A perfect one-time pad gives perfect and unbreakable security.
2) Key sizes are ridiculously short for no reason. They should be in MB, not KB for anything important
3) PKI is badly broken, Key sizes are too small, algorithms are suspect, there are no trustworthy CAs, etc, etc.
4) The weakest link in even well designed systems is the entropy source used for the generation of keys, nonces, salts, etc. </blockquote>
1. OTP is the only perfect security. However, key management is an unsolvable problem as of yet. Once I've exhausted the one terabit key file I sent you, we need to re-exchange again, with no efficient way other than trusted courier. Furthermore, the benefit of asymmetric encryption is that I don't need to know you before hand: All I need to have is your public key. However, OTP (and any other pure symmetric encryption process) all fail the bootstrapping problem with respect to trust and key exchange. With respect to other symmetric options, we would need to exchange a password before we could ever communicate electronically.
2. MB (or Mb) sized keys would be ridiculously inefficient, and provide no improved security over the standard 256 bits of security we want now. Focusing first on asymmetric encryption: RSA's security to efficiency ratio peaks at 3072 bit key size, which is ~115 bits of security. After that, the gains are minimal compared to the massive increase in the size of the key. Elliptic curve cryptography is the next stop, with a much cleaner conversions between asymmetric key size and symmetric key security, 512 bit ECC = 256 bit symmetric.
SInce encryption strength is typically evaluated in terms of symmetric keys, we can now assume that all complexities are functions of symmetric bit size. Now we get into physical limits of the universe, and something called Landauer's principle (this is an excellent overview of the details: http://security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity). Basically though, it states that 128 bits of security will be broken in 2040, which practically translates into 2050 being the year your key is broken, given that we consume the entire planet's energy resources, which was consumed in a decade, starting in 2040. There's some unrealistic assumptions in there that make this an unrealistic best guess with respect to the timeframe.
Now, the other concern to this is that there is an efficient algorithmic break that drastically reduces the key space to evaluate. Of course, if this is true, then any size key using the same algorithm, will be susceptible, and thus no gain.
4. Technically, salts do not need to be random, or even unique. They just are appended to existing passphrasses avoid rainbow table cracking. These are no longer an acceptable practice, thanks to GPU hashing. Much better would be to utilise something like bcrypt, scrypt or PBKDF2, which are not designed to be computationally cheap. That said, I agree that entropy is a failure point, and we need multiple independent sources, mixed together, to counteract suspicions like those about Intel's chip flaws.
@Archimedes_Circle:
Re: efficiency, etc.
The most efficient would be cleartext -- no need to process at all. Heck, if you are worried about cost, give the cleartext directly to the attacker and ask them to send it for you.
If it is *feasible* and it increases security then it should be at the very least possible as a part of the design. Current designs limit key sizes to particular values and there is no valid reason for that. It makes me suspicious, but whatever the case, I am not going to do this for my own stuff.
The above is part of the reason that I said that this is still a problem for non-techies. Anybody who cannot build encryption tools themselves is stuck trusting persons unknown and we know for a fact that at least of some of that trust has been violated and is misplaced.
I presume that if you are talking about RSA and Elliptic curve you have some notion about this stuff and if you do then you either know or can easily find out that there are some profound questions about this stuff.
I am unclear -- are you telling me that you would protect important secrets of your own with those tiny keys because you are confident nobody can strip away a few bits of complexity? Maybe you are right in which case my stuff will be overkill. I suspect that at least as far as we are talking about 115 bits, you are mistaken and we will both live long enough for that to be apparent.
If, in what you appear to think is an unlikely enough event to bet your security on it, I turn out to be correct, my stuff still has some chance of remaining secure while your stuff does not.
Re: "Technically, salts do not need to be random, or even unique"
Note: It is a nit, and I expect perhaps a typo, but if you are going to build salts into your system with forward CBC then you should *prepend* the salt, not append it.
I am not sure of what you have in mind, but re-using the same salt to, for instance, secure passwords is a known security weakness that radically lowers the cost of attack. If, in theory, all attack keys are tried at random then I suppose a non-random salt might be equally effective as a random one. From what I know of attacks on such things they are not at all random.
Rainbow tables come from somewhere. There may not be a rainbow table for your particular salt, but then again there may be. If it is a particularly valuable target that uses a knowable salt for every value, then a rainbow table specific to that salt could be generated at roughly the same cost as any other rainbow table.
People are always going to be surprised by the unexpected. One way to minimize this is to expect more. Generating a random or strong pseudo random salt for every encryption you do is just good practice. Worst case it is a trivial bit of extra work for nothing. We are at a bit of an impass because you obviously can't see how compromised salts can be an issue and I am unable to see how they could not be.
We agree on the multiple sources. Even if your entire communications infrastructure is heavily compromised as long as you can get one good key you can secure end to end.
"People are always going to be surprised by the unexpected. One way to minimize this is to expect more. Generating a random or strong pseudo random salt for every encryption you do is just good practice. Worst case it is a trivial bit of extra work for nothing. We are at a bit of an impass because you obviously can't see how compromised salts can be an issue and I am unable to see how they could not be."
Not necessarily. That's what contingency planning is all about. The thing is to plan for
But back to the thing about key sizes. In the real world, the key size hits realms of diminishing returns, plus there are issues of bandwidth and storage limitations AND they don't account for all possible avenues of attack like insiders or pwning. Ultimately, security is a risk assessment. Since perfect security is impossible, even WITH a one-time-pad, it becomes an exercise in just how far one is willing to go to be secure. At some point you hit the sweet spot where beyond that you reach diminishing returns: where it's more effort than it's worth in trying to thwart your attack (such as in making the key large enough or quantum-resistant, the adversary switches to the new path of least resistance).
That's why practical secrets like Formula X (the Coca-Cola recipe) or the WD-40 oil ratios aren't kept in electronic form at all. It's kept by a very small inner circle who performs the mixing in a black box--ingredients go in, the desired product goes out. Even then one could learn some things (at least a maximum) from the ingredients that go in, but they probably don't use everything and intentionally waste some things to throw off the trail. But that's the kind of risk assessment they made with this system.
As for the multiple sources issue, that goes back to the Trent problem. If ONE source can be compromised, how can one be certain they're not ALL compromised? Particularly by using the one compromised source to reach out to all the rest like a plague?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
