using multiple encryption methods on one file

Hi,

As some of you are aware, part of the discussion over here: https://www.wilderssecurity.com/showthread.php?t=321583

Has to do with the feasibility of using more than one cipher to encrypt the same data.

As Justin and others have pointed out, doing this would most likely substantially increase the risk of there being an exploitable cipher implementation flaw, which could be far more serious than the mathematical weakness of each individual cipher by itself.

While I think that I do understand this concept in theory, I'm finding it difficult to imagine a practical example.

Let's say that data A is encrypted with AES, and later the output from AES (the ciphertext) is encrypted again with, say, Serpent.

In what way could this increase the chance of there being an implementation flaw? Would the implementation design flaws of AES and Serpent somehow 'merge' together, revealing even more implementation flaws? The way I see it, nothing has really changed; a potential attacker would first need to separately break AES (using different kinds of attacks and/or exploiting a possible implementation design flaw unique to the given AES encryption software). After the attacker manages to do that, he would have to repeat the whole process entirely separately for Serpent. If anything, it seems to me that this would increase security, but I cannot think of a way of how it might lower it.

My request: could someone give me an example of how using two ciphers might, in practice, lower security instead of increase it? Please note that the example doesn't have to be "real"; it should just be detailed enough so me and others can understand the actual mechanism that is taking place when 2 or more ciphers are being used.

Thanks.

 

The math behind it is more complex than I can understand. But a flaw in either encryption method could undermine both methods.

The thing about encryption is that each cipher is tested as-is. It's designed as-is and that's it. So when you start mixing and matching you're not necessarily going to get expected results.

This is actually one thing that not every one agrees about as far as I know (and by "everyone" I don't mean th epublic, I mean people who study crypto) and there are both potential pitfalls and potential benefits.

I'll be watching this topic for more input.

 

Hi Hungry Man.

Yeah, this is the way I understand it, but it is also exactly the reason I created this thread - because I cannot think of how this might actually "happen" in practice.

The part I don't get is this: in what way does it matter that what Serpent is encrypting is actually AES-encrypted data? What is the difference, from a mathematical / implementational point of view, between using Serpent to encrypt any random kind of data (like say a notepad file), and using Serpent to encrypt an AES-output cipher text? I mean, both are just bits of information - I can't see how these bits might "pass on" any AES-related implementation issues over to the Serpent cipher.

It is a bit difficult to explain my point, so I hope it's understandable.

 

There are two cases:

#1 - TrueCrypt Cascade Style

The input is encrypted once with AES then that encrypted output is encrypted with serpent and than that encrypted output is encrypted with Twofish.

In this case and implementation problem could exist due to one program encrypting the same file multiple times. I read a white paper that concluded cascades do (if implemented properly) give you a 1% increase of security.


#2 - Septate Programs.

This is where you use two programs to encrypted the same file. Say for example the file is first encrypted with AES using Truecrypt and than Two Fish using a different program. This is done as so:

Plain Text --> TrueCrypt ---> AES Cipher text ----> TwoFish Program ---> Cipher text.

You have now encrypted it twice and in theory since each program only focused on one implementation in this case there should be no security risk.

 

IIRC, some were basically arguing in that thread that a chain, simply because it is more complex to implement than a single, would be more prone to an implementation bug or weakness than a single. IMO, that really isn't about chaining per se but rather the load on the programmers/testers. I think someone who adheres to that philosophy would also have to argue that a product that implements two individual methods is less secure than a product that implements one individual method. When considering such a POV, I think one also has to consider the idea that someone who is competent enough to be implementing one single method is likely to be competent enough to implement two single methods and also chain those two.

Over and above that there is the potential issue of two methods (as implemented) interacting in a way that somehow weakens their combined strength. Is it possible for the two chained methods to mathematically interfere with each other in some way that can be detected and help an adversary zero in on the methods used and/or narrow down something else? I've often wondered if that is possible, but never attempted to research it.

 

You captured the argument well, and make a good point regarding the competency of those implementing cryptography; it may very well be the case that if they can get a single primtive right, they can get multiple primitives right. On the other hand, because they're not cryptographers, I try not to burden them with design decisions that offer little in practice. There are so many subtleties in real-world cryptography from which I'd like to spare them whenever and wherever possible.

Naturally, as you'd expect, cascades are more involved than a single primitive, and because of that, they introduce more code. When you introduce more code, you introduce more complexity, and the likelihood of getting the code wrong is a stack of magnitudes greater than the likelihood of your system falling apart due to using a single primitive. I always look at the trade-off, and use history, and personal experience, to guide the trade-offs I make.

(The following is from a different thread from the past, but I'll paste it here to make it easier.)

Serpent's co-designer, Ross Anderson, echoes this. Read Ross's thoughts on this on page 94, in Chapter 5 of his book, Security Engineering: A Guide To Building Dependable Distributed Systems. Quoting Ross:

While it's possible that two designs could intefere mathematically, I don't think this would be a problem with modern primitives like the AES, Serpent, Twofish, and so on. I've personally never encountered this in practice, but can imagine some very contrived examples.