you can test yourself for correctness of encryption

Simplicity.

Indeed, I haven't evaluated most of the cryptographic software discussed here, so I can't, and don't, make any concrete statements regarding source code. I do, however, make general assessments based on presentation, which can tell you a lot about the cryptographic decisions being made behind the scenes. My criticisms are based solely on cryptographic decision-making, resting on the assumption that the implementation is correct and secure, which it may or may not be.

My take on this matter is pretty simple to follow, and if you ever work on projects that require the practical implementation of cryptographic primitives and protocols, it will become quite evident. That being, implementation attacks are a stack of magnitudes more likely than cryptanalytical attacks, and the added complexity associated with implementing multiple encryption often adds to the likelihood of the former. The trade-off makes no sense. The "just in case" argument doesn't hold up.

If it's agility you advocate, modular design is a smart way to go about it. Keep failure local. Minimize dependencies. Simplify interfacing between modules. That sort of thing. There's a way to allow for "plug-in" functionality without cramming things in from the get-go. Simplicity is empyreal in security; it's complexity that gives us problems - not cryptography. If you design with minimalism in mind, from the ground up, you cater to such simplicity.

Simplicity is, by far, the highest priority when it comes to getting security right, so I tend to give praise to designs that echo this whenever and wherever possible.

 

I use Truecrypt and it is a good program. Having container based encryption and WDE is fantastic and the Truecrypt team have done well. Usability is also very good.

However, regarding Justin's point (or my take on it at least), the problem of having good cryptographic ciphers has been solved. Rijndael is the standard and it should be used. No additional benefits are gained from having a 'choice' of ciphers with even more 'choice' of cascades.

Think about it from a risk perspective. Let me define risk first. For example, we expect X to occur. The question is will X actually occur? Risk is the variability of what actually happens relative to our expectation of X occurring. So if someone says X is risky, it means that what actually occurs is more likely to be different from our expected X. If someone says that X is not very risky, it means what actually occurs is more likely to be expected X. If someone says that X is risk free, what actually occurs is always our expected X. So we have defined risk, but what causes it? In real life, one of the main factors why something is risky is because of uncertainty and our lack of knowledge. This is the case with ciphers.

Let's apply to the our current case of ciphers. We expect our crypto system to not be broken. The risk that this does not occur is can be broken in to two parts, 1) the cipher is broken 2) the implementation breaks.

For ciphers, take Rijndael Serpent and Twofish. All are good algorithms. Look back at November 2001 when Rijndael has just been announced the AES winner. We expect that they will not be broken. At this point all three algorithms have been scrutinized to around the same degree. Because of this, we also assume that the RISK of each of the three not being broken (to a point where it is trivial to crack) is the same. Given the processes these ciphers were tested, we assume (rather reasonably) that the risk is low.

Fast forward to today. Because there has been so much cryptoanalysis on Rijndael, there are less uncertainties surrounding this cipher and hence the risk to our expected result of Rijndael not being broken is even less. Serpent and Twofish, will not have been exposed to as much cryptoanalysis although the risk to our expected result that they are broken is also lessened. Hence all of these algorithms, are strong and the risk our expected result that they are not broken is very low, though this risk is lowest for Rijndael.

The above paragraphs referred only to the ciphers in isolation however and did not consider implementation. Sadly the risk that a particular implementation is broken is much higher than any risk that the cipher itself is broken. In a crypto system the cipher itself is never the weakest link. It is always the implementation that is most prone to mistake and riskiest. Justin's point is (again this is just my interpretation) that developers should minimize the risk, use AES (least riskiest cipher) and keep the implementation simple (which is the riskiest part).

The biggest problem is that consumers demand 'choice' and want riskier ciphers and riskier implementations.

 

I understand your perspectives and I agree to a large extent. I would like TrueCrypt as much if they had just stuck with AES. But the fact that they decided to go with a few additional ciphers and cascades is by no means a deal breaker, or even something that would make me look twice. The developers have proven time and time again that they make good decisions.

Regarding just sticking with AES, I do have one problem with it. If every cryptographic program uses only AES, the other ciphers essentially become obsolete. You could argue that some developers can stick with only Twofish, others with only Sepent, etc. But I don't think a program that doesn't have AES is going to be very marketable.

To me, discarding these other ciphers is unacceptable on principle alone. Based on our current knowledge, these ciphers are just as good as the AES. The only difference is that Rijndael was able to win a contest (judging speed and security, among other things) sponsored by a federal agency (the NIST). It seems contrary to everything I know about security to limit your options like this. It's just human nature to want more than one option, especially when security is concerned.

Now look at TrueCrypt's implementation. They're not implementing every cipher ever devised. They have a very limited offering, AES, Serpent, and Twofish (with cascades involving some combination of these). These were all AES finalists and are widely considered just as strong as Rijndael. It's not like they're using DES or some other weak cipher. I believe they used to use Triple-DES but have since removed it from their offerings.

Now look at how often they've had to change their mode of operation or their hash algorithm based on some perceived security issue. They initially used CBC mode, then LRW, and now they're using XTS. I don't know if they used anything prior to CBC. They currently offer 3 hashes. They dropped sha-1 because of security issues, even though those issues probably didn't affect the implementation in TrueCrypt. Now, the major thing with all of this is that every container previously created by any version of TrueCrypt can be opened by the current version. That means if you used Blowfish/CBC/sha-1, TrueCrypt 5.1a can still open and read/write to it, even though Blowfish, CBC, and sha-1 are all no longer offered as options for new volumes.

I will admit that some of the above does concern me. If ciphers, hashes, and modes continue to be updated/upgraded, I'm not sure how they're going to be able to keep up with all of their previous implementations. They may eventually have to drop support for their previous implementations for simplicity's sake. But the other side of the coin is that if I'm still using one of their older (but still secure) implementations, I don't want to see them drop support for it. I think they should support any previous implementation for at least 5 years after they stop offering it as an option for new volumes.

So, Justin's points are well taken. Things can eventually become very complicated for the developers. But there's also much more that they have to be able to keep track of than their current ciphers. I think offering AES, Twofish, and Serpent is a nice compromise between offering 10 and offering just 1. And the TrueCrypt developers have shown to this point that they can handle a little added complexity. Even if they had offered only AES to this point, they've still added a certain level of complexity due to the fact that they've been changing their mode of operation over the years (due to security issues). They would still have to continue to support CBC-AES, LRW-AES, and XTS-AES.

 

I also wanted to add another thing about TrueCrypt. Look at their list of supported operating systems (staggering) and new/planned features. Their list of ciphers is but one of many of their complex undertakings. In my opinion, what they've managed to offer is nothing short of amazing. And they keep piling on the list of new features they plan to implement.

And, meanwhile, through all of these new developments and innovations, the software continues to function flawlessly. I don't know if their ambition will eventually become a detriment, but it hasn't to this point.

 

Less is more.

The situation with the AES is cryptographically significant. Standardization is a cryptanalytical pheromone, so to speak. The AES, as a standard, is receiving more attention than any other block cipher, and obviously so. Given that cryptanalysis is how a primitive "earns its bones," it's equally obvious as to why this is a good reason to recommend the AES whenever and wherever it's suitable. As I've mentioned in the past, I have no qualms about the use of other secure block ciphers, such as Twofish and Serpent; there very well may be niche applications that impose environmental constraints for which these two, or others, are more suitable.

However, tossing in Twofish and Serpent "just in case" the AES is broken doesn't fly; the likelihood of making a mistake implementing the former two is much greater than a practical attack surfacing for the latter one. When you deal with cryptography in practice, your design decisions should reflect the reality of risk. It's not the design of cryptographic primitives that gives us problems; it's the implementation of cryptographic primitives that throws us. Consumers often have the naive urge for more, when, in fact, less is more when it comes to security. The more options, the more complexity. Simplicity through minimalism makes sense.

Many realize that when cryptography fails in practice, it's almost never because of the cryptography itself; it's because of the implementation. Of course, cryptographic breakthroughs can happen, despite our expectations, and modular designs make transitioning a whole lot easier. Not only that, but modularity facilitates analysis:

It's all about minimizing the most likely threat. You have to be careful not to pile on too much cryptography, lest you reach the point of diminishing returns, while magnifying the much more imminent threat of implementation mistakes. Make smart trade-offs with tangible benefits. If you're minimizing a less likely threat at the expense of maximizing a more likely threat, then I'd say that you're making a lousy trade-off. If you fail to get the threat modeling right, from the very beginning, then, well, I wouldn't place any bets on the road ahead.

 

Re: Less is more.

By the way, can you give some examples for this, please?

 

Re: Less is more.

I suppose the recent Debian/OpenSSL debacle would be one.

 

Indeed, but one has to admit that Debian is far from "keeping things simple".

Wasn't there also something with Windows random number generator?

 

You could also see it the other way: the developer who introduced the bug was merely trying to "fix" the base application, he wasn't even trying to add extra functionality.

Now imagine what can go wrong if someone decides to implement additional features just for the sake of it; I think that's what Justin is trying to convey, that it is FAR more likely someone making an accidental mistake and compromising the whole cryptosystem then any major advance in cryptography rendering a particular algorithm insecure.

 

Re: Less is more.

Simplicity equaling security does not only apply to the cryptographic aspect of the code. Simplicity in the whole package is equally important. And, from what I recall, the PGP Desktop code is far more complex than TrueCrypt. I've never used PGP, but I did take a quick glance at their source code a few years ago, so I might be mistaken. But, from what I remember, it was much larger and much more complex than TrueCrypt. Granted, they do e-mail crypto as well as disk encryption. But still, I have a gut feeling the TrueCrypt developers could teach PGP a thing or two (or three) about streamlining and simplicity. The fact that PGP only uses AES (if that's what they actually do) does not make their implementation simpler. If I want to go with simplicity, I'll use TrueCrypt every time. It's clear to me simplicity was indeed their goal from the beginning, regardless of the fact that the crypto is not as simplified as it could be.

And, to me, it seems counterintuitive to recommend PGP over TrueCrypt for reasons of coding simplicity. As far as I can tell, in almost every other respect besides those you mentioned, TrueCrypt is the simpler and more streamlined option. From what I remember, PGP Desktop was a behemoth compared to TrueCrypt. Simplicity is precisely the reason I started using TrueCrypt in the first place.

And I realize what you're saying about consumers feeling that throwing on a bunch of extra ciphers and multiple encryptions being safer. But explaining to consumers that this is not true should not equate to telling consumers to steer clear of products that offer extra options beyond what's strictly needed. I'm not saying that's what you're doing, but I just wanted to make my point that we don't know the reasons why TrueCrypt or other products offer these options. The TrueCrypt team is notoriously quiet. They rarely talk even on their own boards. So, I have no idea what their reasoning is. But, based on the skill they've demonstrated to this point, I think they deserve the benefit of the doubt. I'm not going to assume they've used any faulty reasoning until they give me real reason to do so.

Was it even a developer who made the mistake? I thought it was a package maintainer who messed with things he shouldn't have (after the developers finished their work). I don't think this case illustrates Justin's points as much as it shows that open-source is not necessarily as secure as people believe, and that closed source does have its benefits.

But I'm still going to stick with open-source where security is concerned.

 

Re: Less is more.

You're right, I used the incorrect term, my bad.

 

Well compare Truecrypt in the current form with multiple ciphers and cascading options to (hypothetically) Truecrypt with just AES. Less room to make mistakes in implementation.

 

I had a whole reply to this that was lost, so I'm not going to bother to re-type it, considering you only had one sentence that's not saying much. But I'll give a short summary.

PGP has a much larger and more complex source code. So they have more potential to make mistakes. The contention that you shouldn't use TrueCrypt because of this issue is hard to swallow. What are your alternatives? If you want to bash the the best program on the market with this issue, you're going to quickly see you have no alternatives anywhere.

 

Simplifying the cryptographic aspects.

Well, I've worked on a lot of projects alongside developers who were responsible for implementing cryptography. More specifically, I've conducted analysis on implementations and out of all the points of failure, not one was cryptographic; they were all implementation flukes - many of which were attributed to complexities introduced by cramming in too much.

Of course, but my comments are within the context of the cryptographic aspects.

Again, my comments are within the context of the cryptographic aspects.

Nor does TrueCrypt's usage of multiple cryptographic primitives make it more secure. However, my comments aren't about the simplicity of the implementation as a whole; they're about the simplicity of the cryptographic aspects of the implementation. Given that, the implementation of a single secure cryptographic primitive does make things a lot simpler.

I don't recall recommending PGP over TrueCrypt, but I do recall saying that if there is anyone I trust to do cryptography the right way, it's PGP Corporation. Furthermore, I don't recall saying that one shouldn't use TrueCrypt, so my apologies for any such implications. In other words, this isn't a PGP versus TrueCrypt debate, nor has it been at any time.

The open-source model has the potential to render the most secure designs, but imagine a scenario where a closed-source implementation has been subjected to hired expert analysis, while an open-source implementation hasn't received any. When subject to expert analysis, the open-source model is empyreal; otherwise, an open-source implementation is no better than a closed-source implementation, if neither have been analyzed. I think that's obvious, though. Bottom line: Being open-source should be instinctive in one's approach to secure design; it's that important.

My point is centered around the idea that any secure design will have its priorities in order, and getting the implementation right is certainly at the top of the list. Simplistic, minimalist approaches cater to getting the implementation right; this involves recycling cryptographic primitives to achieve various goals, such as using the AES for encryption (e.g., AES-CTR) and authentication (e.g., CMAC-AES). Cryptographically, this is quite conservative, and it addresses the highest priority: the implementation. As aforementioned, that's where things go wrong; it's rarely ever because of the cryptography. Good cryptographic design decisions reflect this.

I'm not saying TrueCrypt is bad, per se, because the developers chose not to go this route; it's reasonable to say that there's room for improvement, though. That's all I'm getting at.

 

Re: Simplifying the cryptographic aspects.

Well, you trust PGP and I trust TrueCrypt (and PGP for that matter), so it was bound to turn into a competition eventually. But I accept your reasoning in your last post.

If this is an improvement, it's something they can do in one day. Simply getting rid of everything besides AES would be trivial. Of course, they would still have to support all of their previous implementations, so, if they decided to do it, this change really wouldn't take effect until well into the next decade, possibly Truecrypt 8.0 or 9.0.

But, as I've said, I think a lot of what they include has to do with consumer demand. I don't presume to speak for the developers, but I think that even if they were convinced your views were right, they would never get rid of cascading options. The reason for this is that you would have to convince consumers your views are right. And, in all honesty, that will never happen. More is always better to consumers.

I doubt the developers are willing to lose business over this issue. So, while I agree with what you say about simplicity, I would only question a developer who is actually implementing overly complex solutions because they truly believe those are the best options (and these people do exist). If, however, a developer is willing to handle a little added complexity to meet customer demand, I won't hold that against them or even expect them to change their offering. You'll note that they never state that their cascades are any safer than any single encryption. They never state that AES is safer than Twofish, or vice versa. It's always up to the user, and AES is the default option.

So, to me, it all comes down to the reasons behind the decisions. And, since simplicity has always been a key with TrueCrypt (based on everything else I've seen from them), I'm forced to conclude they have valid reasons for added complexity in this one regard.

But, I also agree with you that if someone is offering a program with unnecessary complexity, non-standard implementations, and making unfounded claims, then that's a program to avoid. A lot of it comes down to what the developers actually believe. Are they using good judgment and reasoning? And a big part of good judgment is meeting consumer demand.

 

I did in fact read your post and it was not 'lost'. I didn't compare Truecrypt to PGP or any comparisons between any other software. Nor did I suggest I prefer one over the other. Actually, in my first post, the only time I mention Truecrypt is when I praise it right at the start.

Let me clarify my second post. It was in response to your post on Truecrypt v PGP (that admittedly has many more sentences ) which I thought was not the right comparison to be making. Instead consider Truecrypt in isolatoin. Truecrypt with multiple ciphers, cascading options and hash functions in this current form has bigger risk of implementations being broken than a simpler hypothetical Truecrypt with only AES and only one hash option. Here I try to make the point if we didn't have all these other 'options', Truecrypt has less risk of implementation failure than in its current form with all these 'options'.

It is sad though. 'Choice' between different ciphers and cascading options is really such an illusion.

 

Better trendsetting.

Their reasons may or may not be good. I'm not forced to conclude either. I'm inclined to agree that it's more than likely a compromise made in the name of consumer demand; then again, the developers may have made these decisions on their own accord. From both cryptographic and implementation angles, a single secure cryptographic primitive makes the most sense, so I see no other reasonable foundation for such decisions. This isn't surprising though, as I've discussed this issue with dozens of software vendors who reiterate the same thing: it's about the consumer.

My hope is that we'll see better trendsetting in the future, and it's going to come through education. It's evident that many consumers care a great deal about security, so it's crucial that we, the cryptographers and developers - the ones that design and deliver their security - educate them towards more fruitful thinking. If "more is better" is the consumer's stance, then there's some paradigm shifting that needs to take place. "Less is more" is the natural direction in which we should shift, and one that reflects the more realistic threat model of implementations being the most likely point of failure.

 

Re: Applying the mortar properly.

Justin,

Thanks for your input on this thread. I would like to ask your views on one scenario where cascading encryption could seem to be beneficial:

Consider a situation where weaknesses (in algorithm or implementation) results in a "feasible" (doable within a reasonable time with reasonable resources) brute-force attack on method X.

Brute force requires that the cracking program is able to identify plaintext, so that it knows when it has chosen the correct key.

If however the plaintext is itself ciphertext, encrypted via method Y (and it contains no identifiable plaintext features like file headers), then this should prevent a brute force implementation from knowing if it had encountered the correct key for X (since it could not distinguish the Y ciphertext from the results of using an incorrect key for X).

While there are downsides to such an approach (having no file headers means the user has to remember the exact details of the cascade used), mightn't this be a case where multiple levels of encryption has a benefit?

 

Sure.

Sure, I suppose this could happen. The paradigm of "not keeping all of your eggs in one basket," as support for using cascades, could be realized too. It's certainly not impossible. My argument is that making an implementation mistake due to the added complexity is much more likely. As we all know - and pardon me for reiterating this countless times, as I do many points - when cryptography falls apart, it's rarely ever because of the cryptography itself, but, rather, the implementation.

If there are two points of attack - one that happens a lot and one that rarely happens - it makes sense to focus your attention on the former, as opposed to the latter. If you start focusing on the latter at the expense of increasing the likelihood of the former, you're downright backwards. It reminds me a bit of the "movie-plot threat" syndrome that Bruce Schneier discusses, in how the countermeasure only works if the movie-plot threat is carried out. I'm in favor of countermeasures that are adaptable and address a broad spectrum of threats - especially threats that are inevitably common.

Quoting myself from a past post in this thread:

I'm not against multiple encryption, though; it can be quite useful. Quoting myself yet again, from a past post in another thread:

The situation you describe could very well take place, but if we look to history as an indicator of where things usually go wrong, it's probably the last place we should focus our resources. Many tend to overemphasize these rare, unlikely situations, while overlooking the more imminent, ubiquitous threats.