you can test yourself for correctness of encryption

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.

 

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.

 

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

 

I wouldn't use it or recommend it.

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.

 

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

 

Trustworthiness.

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.

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.

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.

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.

 

your arguments?

 

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?

 

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.

 

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 ?

 

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"

 

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.

 

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.

 

Multiple block ciphers do not make a product better.

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

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.

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.

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.

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.

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:

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.

 

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

 

Applying the mortar properly.

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.

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.

 

Re: Multiple block ciphers do not make a product better.

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:

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.

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

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.

 

Why do they need more than the AES?

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.

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.

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

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.

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?

 

Re: Why do they need more than the AES?

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.

 

Why would it need more than the AES alone?

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.

 

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

 

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.

 

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.

 

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.

 

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.