you can test yourself for correctness of encryption

[testsoso]

finecrypt clam this:

http://www.finecrypt.net/

the check:
http://www.finecrypt.net/check.html

if this check is relierable, than we have a Program with right implecation of Encryption, and in the same time also allows us to use many different Algorims, beside AES.

[waldovanlaeken]

Fine feature.

Also Truecrypt & FreeOTFE (opensource) and DriveCrypt (securestar - closed source) have this option.

This gives altleast a view on the corectness of the used algorithms.

[LockBox]

Sorry, the feature means absolutely nothing. It cannot tell you whether there was proper implementation. Snake oil.

[Justin Troutman]

I contacted FineCrypt's authors, Crypto Systems Incorporated, somewhat recently, with my concerns regarding their excessive use of "unnecessaries," as I call them; that is, things you really don't need. They use too many block ciphers; they only need the AES. They use too many modes of operation, including ECB, which they've left in, quoting them, "because occasionally some users need it for testing or 'academical' purposes." It's a lousy reason. I can't think of any reason that the average consumer would require the ability to test ECB for an academic purpose. Surely those who require this ability have access to implementations for exactly that purpose. Production software is not the right place for experimental options - especially when they're insecure.

Consumers shouldn't be required to configure cryptographic options; they should be secure by default. There's no reason to allow them to be tweaked. They [Crypto Systems Incorporated] have yet to get back to me regarding these concerns; they did make the comment that they'd take my suggestions into consideration, but I won't hold my breath. As I've discovered, much of the cryptographic software you'll find is built around what looks and sounds good, from a marketing perspective - not a security perspective. After all, most of these products are coming from software vendors, not security folks. I hope this isn't another one of those products, and that they'll make an effort to do cryptography better. At this point in time, I wouldn't use FineCrypt or recommend its use.

[SYS 64738]

So, which encryption software would you really trust?
Can you give a recommondation? And: Whose recommondation is really reliable? Should one get an encryption expert and write his own application?

Don't get me wrong, i estimate your writings very much, it's just that i'm getting more paranoid, when i read about several applications, which are supposed not to be trustworthy... ???

[Justin Troutman]

{QUOTE-> So, which encryption software would you really trust?
Can you give a recommondation? <-QUOTE}

I trust PGP Corporation to do cryptography the right way. Although I haven't analyzed AxCrypt's source code, I have been engaging in dialogue with its author, Svante Seleborg, and it's one of the best-looking approaches to file encryption I've seen thus far; it's the product of a developer having done his homework. Assuming the implementation is correct and secure, it's the closest to achieving IND-CCA2 /\ INT-CTXT security that I've seen in any product. We'd be better off if more products would follow suit.

I'm sorry I can't recommend anything else. There are just too many offerings to sift through and too much source code to look at, and much of the time, the latter isn't available. Although it may seem superficial, you can tell a lot about the quality of the implementation by its presentation. As a metric for discerning between the good and bad, it has been reliable. Unfortunately, though, it's possible for good cryptography to be marketed poorly. Fortunately, I've found that not to be the case, so far. I'll keep my fingers crossed.

{QUOTE-> And: Whose recommondation is really reliable? <-QUOTE}

Well, I certainly don't want anyone to take my word for it, without doing their own research. However, you'll find that my criticisms are supported by good cryptographic engineering principles. I can back this up, if need be. My take on this is that the reliability of one's criticism is measured by how well it's supported; there's no doubt that this can be difficult for the consumer to assess.

If you're looking at a five-cow Tucows recommendation for guidance, for example, then you're looking in the wrong place. Why? Because, the criteria for such reviews does not, and cannot, assess security. if you're reading commentary by Bruce Schneier, for example, then you're looking in the right place. Why? Because, he's a seasoned cryptographer who's well-versed in the black art of cryptographic implementation.

{QUOTE-> Should one get an encryption expert and write his own application? <-QUOTE}

Having a cryptographer at your disposal is grand, but I would never recommend rolling you own. I do, however, recommend that cryptography never be done without a cryptographer on board; in cases where off-the-shelf solutions aren't sufficient, and you need to build an infrastructure from the ground up, this is crucial.

{QUOTE-> Don't get me wrong, i estimate your writings very much, it's just that i'm getting more paranoid, when i read about several applications, which are supposed not to be trustworthy... ??? <-QUOTE}

Some might think, "Justin has it easy. These software vendors spend all of this time designing the software, then he comes along and makes a quick remark to negate its trustworthiness." In reality, I understand completely what it's like to face the hazards of cryptographic implementation; when cryptography fails, in practice, this is almost always where it happens.

I know this well enough to know that I have neither implemented my own cryptography for use, nor have any plans to. We are - myself included - better off using analyzed implementations.

My criticisms are meant to educate developers on what not to do, so they'll have a tighter grasp on what to do; that's why I suggest improvements. I think that's fair. The design and deployment of cryptography makes no room for error, so it's necessary that we, as cryptographers, are strict. That's how things get done the right way.

[testsoso]

{QUOTE-> Sorry, the feature means absolutely nothing. It cannot tell you whether there was proper implementation. Snake oil. <-QUOTE}

your arguments?

[testsoso]

Questions to Justin:

1)http://www.anhuachina.com/rj2-1.asp
here is a password recover software, claim to recover from PGP Disk and Privat Keyring. So is PGP still secure?

2)if everybody use only AES as their encryptions algorithm, will this not encourage people try really hard to break it?

3) is it not all 5 AES finalists provide enough or almost the same level of encryption strength?

4) provide many different Algorithms will discourage people to break the AES, because it is too hard to break them all and not really useful only to break one of them.

5)If the finecrypt can prove that their Program really produce the right result of encryption, so what is the worry? will the check they provid destroy your arguments?

[waldovanlaeken]

Answer to question 2 Imho :

That's just the point why AES is the best choice at this moment. It's the most popular and most used algorithm...so a lot of cryptoanalys on it.

No known attacks for it at this moment. So considered "safe".

question 3 : They ALL (AES-finalists) provide enough security. Becoming the new AES is not only about security though...

It needs to be fast, work in hard & software , easy implentation , small enough code etc.....

question 4 : If it's possibel to really break the AES...Then it will also be possibel in within a short period to break some of the other AES-finalists to.

[waldovanlaeken]

Btw ; about question 1 :

I think it's possibel to recover passwords on most software.

That's why you have to use real strong passwords. And the program will fail >> IF the ecryption algorithm is strong enough and coded well. (like PGP)

https://www.grc.com/ppp.htm

https://www.grc.com/passwords.htm

Proof that for example Bestcrypt (with strong password) can't be fooled :

http://www.lostpassword.com/bestcrypt.htm

Are you gonna run your PIV till the end of time to guess my 64 random caracther password ?

[SYS 64738]

Well, concerning PGP, which whole disk encryption is obviously recommended by Schneier (http://www.schneier.com/crypto-gram-0712.html), i checked the PGP site and read there, that PGP Whole Disk Encryption can be setup in a certain way working with "PGP Universal Server Management". I could not really find out, how this is accomplished, but one feature is to me like a inbuild backdoor: They call it "Recovery Passphrase - Automatically generates and stores a unique one-time-use recovery passphrase to ensure authorized access to encrypted data".

Again, they don't specify how this is accomplished, and maybe i would't even understand, how this works. But, personally spoken, i'm somewhat worried about this "feature" :blink:

[waldovanlaeken]

It's for admins. But only optional.

If someone at the office forgets his password, the admin could reset it.

Ohterwise the owners pc is useless.

Like i said, this is optional.

This is NO breach in security, but a feature.

[SYS 64738]

But how can one be sure, that this feature cannot be used even when one decides not to do this Server Management setup?
I admit, this is useful for company laptops and so on, but i would feel better without this possibility.


Edit: Concerning the use of different ciphers

I think, on would get a higher degree of security using different encryption ciphers. If someone is able to break AES it will not mean necessarily that he is also able to break Blowfish, Twofish, RC6, Serpent, DiamondII and so on. I would expect that this this would take an enomous afford, first to find out, which cipher is used and than start to break it, even if someone knows what to do. But i have possibly a too simple imagination of this: one maybe an adept on AES, but an amateur on serpent.

[Justin Troutman]

{QUOTE-> 1)http://www.anhuachina.com/rj2-1.asp
here is a password recover software, claim to recover from PGP Disk and Privat Keyring. So is PGP still secure? <-QUOTE}

Being able to recover a password and being able to implement the cryptography properly are different things. I was referring to the latter.

{QUOTE-> 2)if everybody use only AES as their encryptions algorithm, will this not encourage people try really hard to break it? <-QUOTE}

That's the most compelling reason to use the AES, because it receives more cryptanalysis than any other block cipher. A cryptographic primitive "earns its bones" through rigorous cryptanalysis; it's how we evaluate the soundness of the design strategies behind it.

{QUOTE-> 3) is it not all 5 AES finalists provide enough or almost the same level of encryption strength? <-QUOTE}

Practically speaking, it probably doesn't matter which of them you use; if failure occurs, it will almost certainly not be because of which block cipher you selected. There may be niche applications where one is more suitable than another, and I'm fine with that. But, if you can, use the AES.

{QUOTE-> 4) provide many different Algorithms will discourage people to break the AES, because it is too hard to break them all and not really useful only to break one of them. <-QUOTE}

This "just in case" mentality is a common fallacy.

It won't discourage the cryptanalysis of the AES. Most of the worthwhile targets are entities that are required, by policy, to implement cryptographic standards. One of the many reasons is liability; that is, if something goes wrong, you can't blame anyone for using a standard. There will always be a huge incentive for attacking a standard.

Let's look to practice, historically, as an indicator of whether or not offering multiple block ciphers is a good thing or a bad thing. In practice, we know that when cryptography fails, it's almost always because of the implementation. Implementations have fallen apart because of developers cramming in a dozen block ciphers, due to the complexity it introduces. It makes analysis more difficult, and we certainly don't want that. This promotes the importance of simplifying implementations through the recycling of primitives. We can do this with the AES, for our encryption scheme, authentication scheme, and PRF (i.e., AES-CTR and CMAC-AES).

When attacks on cryptographic primitives surface, they are usually certificational; in other words, they're academic, or "theoretical," without any imminent real-world applicability. The odds of implementation failure are a stack of magnitudes greater than the surfacing of a practical attack on the AES. Of course, history doesn't guarantee that the future will always follow suit, as far as the extensiveness of attacks goes, and attacks do get better, but we do know, without a doubt, that cryptography will continue to fail in practice because of implementation flukes. We know that this is where things usually go wrong and we know that this is where our attention is needed.

Given the above, offering more block ciphers is clutter, at best, and is prone to causing implementation fragility; it does a lot for insecurity, but nothing for security. Developers worry too much about the cryptography itself, while downplaying its implementation. In reality, it should be the other way around.

{QUOTE-> 5)If the finecrypt can prove that their Program really produce the right result of encryption, so what is the worry? will the check they provid destroy your arguments? <-QUOTE}

No, it won't. My argument is not that FineCrypt is inherently insecure because of its excessive use of cryptographic primitives. My argument is that the excessive use of cryptographic primitives can make implementation mistakes more likely, by making the implementation more complex. When cryptography fails in practice, this is usually why. If FineCrypt is secure, that's great, but having multiple block ciphers does not make it any more secure than if it had a single block cipher. Recycling primitives is good cryptographic engineering; that's what I'm advocating. It makes since to simplify the analysis of the most likely points of failure. Don't worry about the cryptography itself; if implemented properly, it won't let you down. It's the implementation part that stumps us.

{QUOTE-> I think, on would get a higher degree of security using different encryption ciphers. If someone is able to break AES it will not mean necessarily that he is also able to break Blowfish, Twofish, RC6, Serpent, DiamondII and so on. I would expect that this this would take an enomous afford, first to find out, which cipher is used and than start to break it, even if someone knows what to do. But i have possibly a too simple imagination of this: one maybe an adept on AES, but an amateur on serpent. <-QUOTE}

This forms the basis of arguments in favor of using cascades - the "not keeping all of your eggs in one basket" paradigm. I argued against this in the TrueCrypt forum. Quoting from that thread:

{QUOTE-> {QUOTE->
Anyway, let me simplify it (for the sake of those who aren't fans of mathematics). If I give you a plaintext encrypted with AES and Twofish and then Twofish is broken someday, will you be able to decrypt the plaintext? No, because it will still be encrypted with AES. Whereas if it was encrypted only with Twofish, you would be able to decrypt it almost instantly. This is provable and it represents an enormous security advantage over single encryption.
<-QUOTE}

That makes several assumptions. If we encrypt with a cascade composed of block ciphers A and B, and A is broken, we might say that confidentiality is still preserved because B hasn't been broken. Then again, this assumes that the attack on A is beyond that of a certificational weakness (i.e., theoretical attacks with unlikely real-world applicability, which most cryptanalytical attacks are). Furthermore, it assumes that B really hasn't been broken. Perhaps it has been, but analysis hasn't been published yet. Who knows. While it may be reasonable to assume that the confidentiality is still preserved, this isn't something we can prove. <-QUOTE}

The problem is, we have no metric for determining whether or not a primitive has been broken. Perhaps it hasn't been, or perhaps it has been, but its cryptanalysis hasn't been published. When we make design decisions, they should make sense from a cryptographic standpoint and from an engineering standpoint. This type of guesswork makes no sense either way, and only adds complexity to the implementation, which, you'll know by reading the above, is a bad thing.

[SYS 64738]

Ok, i got your point. However, despite of the fact, that i'm using TrueCrypt with cascading cipher, i didn' have this really in mind as is posted. My thought was, if i encrypt several files with different algorithms, it'll be more difficult to decrypt them all. Some of them may be decrypted, others not.

I agree with your statement about implementation. But this leads us again to my earlier post: How can one prove the correct implementation by himself? When I'm able to check this, i would probably be able to write my own encryption software.



And to come back to PGP again: I think this "one-time-use recovery passphrase" feature is an absolutely no-go. If you have a secret, it will be no secret anymore when another person has knowledge of it. let it be the corrupt admin or your best friend.
If they come to PGP telling them, "Ok, we know that you can reset the password in Whole Disk Encryption, can you also do this with non-company laptops? No? Do you think people would like to read, that evidences of this high treason couldn't be obtained because of the unbreakable encryption provided by your company and your unwillingness to cooperate?"
Ok, i admit this is kind of paranoia, but it is just a thought....

[Justin Troutman]

{QUOTE-> Ok, i got your point. However, despite of the fact, that i'm using TrueCrypt with cascading cipher, i didn' have this really in mind as is posted. My thought was, if i encrypt several files with different algorithms, it'll be more difficult to decrypt them all. Some of them may be decrypted, others not. <-QUOTE}

Right, and this goes back to the "not keeping all of your eggs in one basket" paradigm, on which that idea is built; it's logical, and it's not impossible for it to be realized in practice, but practice doesn't indicate this to be likely. Practice does indicate that implementations fail, and will continue to fail, all the time, because of unnecessary complexity, which is why it's better for us to simplify it in every possible manner. Good cryptography is about doing a lot with a little. What folks need to realize is that obsessing over the cryptography itself is a misplaced priority.

Systems don't fall apart because they simply use the AES and nothing else; they do, however, fall apart because a developer decided he needed a dozen more block ciphers "just in case" the AES was broken. It may seem counterintuitive, but when implementing cryptography, the cryptography itself is the one aspect you should be concerned about the least. In regards to TrueCrypt, it's probably a decent application, but cascades don't make it more secure. You can gut it of its multiple block cipher options and cascades, without giving up any security at all.

Look at it this way. Good, properly implemented cryptography is a wall that's already too tall to climb over and too strong to knock over. Adversaries realize this. Do they fret over it? Hardly. They walk around it, because, let's face it, security isn't getting better and there's always easier ways of getting at data. There's nothing cryptography can do about that. There are some things cryptography can do, but the answer is not to keep stacking the cryptographic bricks; the answer is to make sure you're applying the mortar properly.

Otherwise, they're going to knock it over. But, don't go blaming the cryptography. It's your fault for not putting it together the right way. Such is another day in the life of cryptography in practice.

{QUOTE-> I agree with your statement about implementation. But this leads us again to my earlier post: How can one prove the correct implementation by himself? When I'm able to check this, i would probably be able to write my own encryption software. <-QUOTE}

This is a problem, because there aren't many folks with the ability to discern between secure and insecure code. However, we can look for signs that the developers understand what constitutes good cryptographic engineering. Do their design decisions reduce the likelihood of implementation mistakes? That's the kind of question we should be asking. Remember, do a lot with a little! Minimalist design is the key to good design, so I look at designs that seem to follow this paradigm as closely as possible. AxCrypt is a good example, and, unfortunately, the only one I can think of. I would love to hear about others, though. Sadly enough, most seem to obsess over how long the key should be and which block cipher you should use; this is a sign that they've probably overlooked more important things.

[testsoso]

{QUOTE-> That's the most compelling reason to use the AES, because it receives more cryptanalysis than any other block cipher. A cryptographic primitive "earns its bones" through rigorous cryptanalysis; it's how we evaluate the soundness of the design strategies behind it. <-QUOTE}

This is not a compelling reason for me. This doesn't prove AES is more secure than others, it proves only: No known attacks for it at this moment. So considered "safe". like you have said:

{QUOTE-> The problem is, we have no metric for determining whether or not a primitive has been broken. Perhaps it hasn't been, or perhaps it has been, but its cryptanalysis hasn't been published. <-QUOTE}

And it shows also, that more people are interested in attack AES than others, this is like the IE vs FF and Opera, more people rely on it, so more attacks draws to it, and it is most likely that AES will be breaked first. i'm not saying AES is not good, but I think it is more dangerous, if we follow your idea, put all eggs in AES.

{QUOTE-> if something goes wrong, you can't blame anyone for using a standard. There will always be a huge incentive for attacking a standard. <-QUOTE}

we are not ague to blame anyone, but we are alking about which is more secure.

{QUOTE-> Let's look to practice, historically, as an indicator of whether or not offering multiple block ciphers is a good thing or a bad thing. In practice, we know that when cryptography fails, it's almost always because of the implementation. Implementations have fallen apart because of developers cramming in a dozen block ciphers, due to the complexity it introduces. It makes analysis more difficult, and we certainly don't want that. <-QUOTE}

i saw many times you said this, please give me the many exsamples in history, how many widely used software fails because the implementation. and why you think this failuers still not being fixed by the software we have in modernday.


follow your arguments, it is better for the software developer, to focus only use one primitives, and it is more easy for the right implementation, i can understand that, but i think it is not more easier to write many seperated Programs, and each uses only one block cipher, than to write one program which include them all.

[Justin Troutman]

{QUOTE-> This is not a compelling reason for me. This doesn't prove AES is more secure than others, it proves only: No known attacks for it at this moment. So considered "safe". like you have said: <-QUOTE}

It's certainly true that we can't be certain, but the point is to use primitives in which we have confidence. Confidence is a product of cryptanalysis. Therefore, the sensible approach is to use the AES, whenever possible. We want to use primitives that receive the most cryptanalysis; it's a good thing.

{QUOTE-> And it shows also, that more people are interested in attack AES than others, this is like the IE vs FF and Opera, more people rely on it, so more attacks draws to it, and it is most likely that AES will be breaked first. i'm not saying AES is not good, but I think it is more dangerous, if we follow your idea, put all eggs in AES. <-QUOTE}

You seem to be under the impression that the primitives which receive more cryptanalysis are more dangerous to use than the primitives which receive less cryptanalysis. It's actually the other way around. We want to build our protocols on things we know a lot about; there's a much greater risk in fielding designs that haven't seen much scrutiny.

Why do you think the AES is more likely to be broken first? There's no reason to believe that. Another common misconception is the a block cipher with more rounds is more secure, based on "security margins." Assume we have two block ciphers, A and B. A is a Feistel, while B is an SPN. There's a truncated differential attack on A that covers 7 of its 10 rounds and a higher-order differential-linear attack on B that covers 20 of its 40 rounds. On the surface, we can say B is stronger than A, because it still has 20 rounds left untouched, whereas A is only 3 rounds shy of a full break. On the other hand, this starts to lose value, when you consider that we're talking about two block ciphers based on different structural designs, using two different round functions, and analyzed using two different attack models. It could very well be the case that extending the attack on B's remaining 20 rounds is easier than extending the attack on A's remaining 3 rounds. It all depends on what's going on inside the round function and how well we can extend our best cryptanalysis.

{QUOTE-> we are not ague to blame anyone, but we are alking about which is more secure. <-QUOTE}

Pardon me, but I'm not sure what you mean. I think I know, but could you clarify, please?

{QUOTE-> i saw many times you said this, please give me the many exsamples in history, how many widely used software fails because the implementation. and why you think this failuers still not being fixed by the software we have in modernday. <-QUOTE}

Keep in mind that when I talk about implementations, I'm not referring to cryptographic software alone; this represents an extremely minuscule portion of cryptographic implementations. From the experiences I've had working on various projects that required the implementation of cryptography, I know how easy it is for developers to get things wrong. Even more alarming is the fact that I've worked with security folks who get things wrong. Now, consider that a lot of the cryptographic software on the market is the product of software vendors - not security folks. This calls for even more conservatism in design. Cryptography is tricky.

{QUOTE-> follow your arguments, it is better for the software developer, to focus only use one primitives, and it is more easy for the right implementation, i can understand that, but i think it is not more easier to write many seperated Programs, and each uses only one block cipher, than to write one program which include them all. <-QUOTE}

Why do we need to write many separate programs? I can't think of a single application that would be better if it used more than the AES alone. Why do applications like FineCrypt and TrueCrypt (the applications mentioned in this thread) need more than the AES?

[testsoso]

{QUOTE-> We want to build our protocols on things we know a lot about; there's a much greater risk in fielding designs that haven't seen much scrutiny.

Why do you think the AES is more likely to be broken first? There's no reason to believe that. Another common misconception is the a block cipher with more rounds is more secure, based on "security margins." Assume we have two block ciphers, A and B. A is a Feistel, while B is an SPN. There's a truncated differential attack on A that covers 7 of its 10 rounds and a higher-order differential-linear attack on B that covers 20 of its 40 rounds. On the surface, we can say B is stronger than A, because it still has 20 rounds left untouched, whereas A is only 3 rounds shy of a full break. On the other hand, this starts to lose value, when you consider that we're talking about two block ciphers based on different structural designs, using two different round functions, and analyzed using two different attack models. It could very well be the case that extending the attack on B's remaining 20 rounds is easier than extending the attack on A's remaining 3 rounds. It all depends on what's going on inside the round function and how well we can extend our best cryptanalysis. <-QUOTE}

yes we want to build our protocols on things we know a lot about, that's why the "security margins." your argument about the A and B is based on what we don't know, but the security margins is based on passed cryptanalysis. So a block cipher with higher security margins is also most likely more secure. you can only prove your idea by break the cipher. so your argument why should we rely only on AES failed in my opinien.

[Justin Troutman]

{QUOTE-> yes we want to build our protocols on things we know a lot about, that's why the "security margins." your argument about the A and B is based on what we don't know, but the security margins is based on passed cryptanalysis. So a block cipher with higher security margins is also most likely more secure. you can only prove your idea by break the cipher. so your argument why should we rely only on AES failed in my opinien. <-QUOTE}

I think you might have overlooked the fact that the example I've given is the basis for the security margin paradigm. The concept of a security margin isn't a conclusive metric for determining which is more secure. A block cipher with a larger margin of security isn't inherently more secure, or even more likely to be, because it's round function could be weaker than the round function of a block cipher with a smaller margin of security. It's not that I think the concept of a security margin is worthless; it's quite useful as a conservative way to think about cryptographic design. However, it's not as clear cut as it may seem. In the example I've provided, we're discussing two different block ciphers, based on different structural designs, and cryptanalyzed under two different attack models. The problem is how to go about leveling the playing field. Attacks get better, but which attack on which of the block ciphers is likely to get better first? We don't know.

My argument is not that the AES is more secure than any other block cipher. My argument is that the AES, as a standard, receives more cryptanalysis than any other block cipher. This instills more confidence in its design, which is a primary motivating factor for using a block cipher. This type of confidence is a product of cryptanalysis, not a security margin comparison, and I hope you can see why. Of course there are no guarantees, but practice indicates that we should field the most rigorously cryptanalyzed designs. Not only that, but good cryptographic engineering tells us that we should only implement the bare essentials. I think you'll find that other cryptographers share this same view on using the AES whenever and wherever you possibly can, unless there's some reason you can't (i.e., the architectural constraints). Again, I ask, why would an application like FineCrypt need more than the AES? I can't think of a single good reason.

[huangker]

AxCrypt doesn't support Vista however. Are there any programs that can be recommended and support Vista?

[Karen76]

{QUOTE-> AxCrypt doesn't support Vista however. Are there any programs that can be recommended and support Vista? <-QUOTE}

AxCrypt, at least the last two versions, is Vista compatible. Much of the information about AxCrypt's history of releases on Axantum's website is way out of date. The most recent version of AxCrypt, v1.6.4.4, was released on May 15, 2008 and, according to SourceForge.net, is compatible with Vista, XP, 2000, and Windows Server 2003.

I've used the last two versions of AxCrypt on my Vista PC with absolutely no problems.

[malwaretesting]

I just had to add my 2 cents to this. While Justin is well-spoken and obviously knowledgeable about cryptography, I don't think he's personally evaluated many of these programs. I personally have no formal training in cryptography.

DriveCrypt Plus Pack would be an example of one of those WDE programs that's very poorly marketed. They make claims like 1344 bit encryption and military grade, etc. But practically, it's a very well made program. It's been around for a long time. Prior to version 3.0, they had a problem with IV generation that led to a non-random appearing, repeating ciphertext. This was corrected in 3.x, and I've noticed no problem with it since. It's closed-source, but I would have no problem putting anything on a drive encrypted by this program.

TrueCrypt is a brilliant open-source program that's been evaluated by many experts over the years. They've recently added WDE to their traditional partition and file-hosted volumes. This is the first truly open-source WDE product. Sure, they use cascades with AES, Twofish, etc., but they only make use of a limited number of these cascades. Some people simply demand that they offer other alternatives besides AES.

There's nothing wrong with offering Twofish to those that don't want to use AES, when you consider that Twofish is just as secure as AES. Some people want to use cascades. They don't use any weak algorithms. There's no reason for the developers to shoot themselves in the foot to stand on the principle of using the simplest implementation possible. But, just take a look at the size of the TrueCrypt program and its source code. Compare it to other programs and you'll see how streamlined and efficient it really is. This is a relatively tiny program that can do simply amazing things. And it does them flawlessly. I can't recommend this program more whole-heartedly. It's in a class all it's own. And I'm not affiliated with them in any way. It's just that good.

[huangker]

Just because a program hasn't been evaluated from a user perspective, doesn't mean it hasn't been evaluated from a crypto design perspective.

[malwaretesting]

{QUOTE-> Just because a program hasn't been evaluated from a user perspective, doesn't mean it hasn't been evaluated from a crypto design perspective. <-QUOTE}

Are we talking about Justin? Okay, then let me be more specific. I don't think he's evaluated many of these programs from a crypto perspective. I would trust his opinion, but he hasn't given a specific evaluation of anything except PGP. The rest were criticized generally because of "unnecessaries". I can appreciate that, but I don't think TrueCrypt falls into that category. It's a very light program that's obviously being developed by people who know their stuff. It's been evaluated by countless cryptographers. I can't say that it will continue under the same development team in the future. I've seen many great programs die a horrible death after a new team takes over. And many of Justin's points may definitely be valid in the future, if new people take over the project. But right now, TrueCrypt is definitely the one to beat.

Here's a quote from Justin to back up that he has not evaluate many of these programs:

"I'm sorry I can't recommend anything else. There are just too many offerings to sift through and too much source code to look at, and much of the time, the latter isn't available."


I'm sorry if I'm being harsh, but I think TrueCrypt is too good to be muddled in with a bunch of other programs under the banner of "unnecessaries". There's a valid reason for their choice of cascades, and it's not necessarily anything to do with security. Sometimes your customers demand something, and you have no choice but to comply. I agree with Justin that AES is probably enough, but many (or maybe most) consumers won't agree. And to be fair, I like having the option of cascades. For home use, AES is good. But if I want to store something for 20 years, you can be sure I'm going to use a cascade.

The old AES-Blowfish cascade they had proved to be resilient against a certain attack that any single encryption would have been susceptible to (although still not a practical attack). So, while everything else was susceptible, AES-Blowfish (and AES-Blowfish-Serpent) was not. Of course, that was in version 2.x or 3.x, and they've changed everything since then, so all their implementations are secure now. But it's a good example of why you want some variety.

[Justin Troutman]

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.

[huangker]

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.

[malwaretesting]

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.

[malwaretesting]

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.

[Justin Troutman]

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:

{QUOTE-> 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. <-QUOTE}

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.

[SYS 64738]

{QUOTE->
Many realize that when cryptography fails in practice, it's almost never because of the cryptography itself; it's because of the implementation.
<-QUOTE}


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

[N_A]

{QUOTE-> By the way, can you give some examples for this, please? <-QUOTE}
I suppose the recent Debian/OpenSSL (http://www.schneier.com/blog/archives/2008/05/random_number_b.html) debacle would be one.

[SYS 64738]

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

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

[N_A]

{QUOTE-> Indeed, but one has to admit that Debian is far from "keeping things simple". ;D <-QUOTE}
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.

[malwaretesting]

{QUOTE->
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.
<-QUOTE}


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.


{QUOTE->

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.
<-QUOTE}

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.

[N_A]

{QUOTE-> 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) <-QUOTE}
You're right, I used the incorrect term, my bad.

[huangker]

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.

[malwaretesting]

{QUOTE-> 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. <-QUOTE}

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.

[Justin Troutman]

{QUOTE-> By the way, can you give some examples for this, please? <-QUOTE}

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.

{QUOTE-> Simplicity equaling security does not only apply to the cryptographic aspect of the code. <-QUOTE}

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

{QUOTE-> Simplicity in the whole package is equally important. <-QUOTE}

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

{QUOTE-> The fact that PGP only uses AES (if that's what they actually do) does not make their implementation simpler. <-QUOTE}

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.

{QUOTE-> 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. <-QUOTE}

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.

{QUOTE-> But I'm still going to stick with open-source where security is concerned. <-QUOTE}

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.

[malwaretesting]

{QUOTE->


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.

<-QUOTE}

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.


{QUOTE->

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.

<-QUOTE}

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.

[huangker]

{QUOTE-> 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. <-QUOTE}

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.

{QUOTE-> 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. <-QUOTE}

Let me clarify my second post. It was in response to your post on Truecrypt v PGP (that admittedly has many more sentences :P) 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'.

{QUOTE-> 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. <-QUOTE}

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

[Justin Troutman]

{QUOTE-> 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. <-QUOTE}

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.

[Paranoid2000]

{QUOTE-> Systems don't fall apart because they simply use the AES and nothing else; they do, however, fall apart because a developer decided he needed a dozen more block ciphers "just in case" the AES was broken. <-QUOTE}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?

[Justin Troutman]

{QUOTE-> 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? <-QUOTE}

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:

{QUOTE-> 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. <-QUOTE}

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

{QUOTE-> Semi-recently, there has been some intriguing research with regards to the CCA-security of multiple encryption constructions, cascades included. I recommend checking out, "Chosen-Ciphertext Security of Multiple Encryption (http://people.csail.mit.edu/dodis/ps/2enc.ps)," by Dodis and Katz, as well as "Tolerant Combiners: Resilient Cryptographic Combiners (http://eprint.iacr.org/2002/135)," by Herzberg. I have no doubt about the potential security and functionality that the application of multiple encryption can provide, in a variety of contexts, which echoes the importance of establishing its security beyond IND-CPA (e.g., IND-CCA). <-QUOTE}

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.