# Tag Info

21

Cascading cipher gives a sense of security; and one that is technically justified with respect to the possibility that a weakness in one of the cipher would allow recovering the encrypted data. That's Bruce Schneier's argument, and it made sense in an era where DES, the then leading cipher, was a closed design, clearly deliberately weakened by a small key, ...

11

If you combine two affine ciphers, you obtain one affine cipher. Say the first cipher is $e_1(x) = a_1x+b_1$ and the second is $e_2(x) = a_2x+b_2$. Then $e_1(e_2(x)) = a_1(a_2x+b_2)+b_1 = (a_1a_2)x+(a_1b_2+b_1)$. Note that if $a_1$ and $a_2$ are both relatively prime with the modulus, then so is $a_1a_2$, so the new cipher can also be deciphered.

10

The usual method to do this is to turn the block cipher into a stream cipher. In that way the ciphertext is generated by XOR'ing the plaintext with a generated key stream. This key stream in turn is generated by the mode of operation that turns the block cipher into a key stream. There are several of these modes, but CTR mode of operation is most often used ...

9

Can double-encrypting (with either the same or separate algorithms) weaken security? If you do not assume that the algorithms and keys are independent, then it certainly can. The example of ROT13 from the other answer illustrates the point even if it is not real encryption. Similarly, a synchronous stream cipher applied twice with the same key will ...

7

EEE and EDE are effectively the same in terms of security. EDE is used because it is "backwards compatible:" by setting all three keys to be the same, it becomes equivalent to just single encryption (E) with that key.

6

I don't know about computing things in parallel, so I will ignore that part of the question. First, please note that the encryption algorithm is rarely the the weak point of the security. It is far more likely that you will have problems with the implementation, some spyware installed on your computer, a weak password (If you use qwerty as your password, ...

6

There is a very interesting paper that relates to this exact question (but you wouldn't guess it from the title). The paper is titled Efficient Dissection of Composite Problems, with Applications to Cryptanalysis, Knapsacks, and Combinatorial Search Problems. In Section 3, the paper considers the multiple encryption problem and gives novel attacks that are ...

6

The answers and comments here are good, but I think that it's worth tidying it all up a bit. The question is broad, and this is exactly expressed in the answers. There are multiple questions here. Before I begin, I note that when we talk about the keys not being "independent", we need to define what we mean. I am only going to relate to the keys being the ...

5

I won't say someone would be able to break it 'easily'; however it won't be anywhere as difficult as with a true 128 bit cipher (or even 120 bit cipher; your construction ignores 8 of the key bits). Here's an outline of how the attack would work: we assume we know the plaintext and the ciphertext, and are trying to recover the key. When we do is encrypt ...

5

I can see based upon your question that you're not already a crypto-expert. Given that, I think the single most useful answer I can give you is this: Multiple encryption addresses a problem that mostly doesn't exist. Modern ciphers rarely get broken -- at least, not in the Swordfish sense. You're far more likely to get hit by malware or an ...

5

Well, whether $AES'$ is as secure as $AES$ depends on the length of $k_1, k_2$. If they are both 128 bit, then what you effectively have is a standard 128-bit AES, except that prior to round 6, you replace the running key with an independent key (and you tweaked the last round, but that's cryptographically harmless). Now, it is never a good idea to do ...

5

Step 1: good job, this is the right way. You can also use bcrypt or scrypt for extra resistance. Make sure you have chosen sufficiently strong parameters, that is, 64-bit salt and 10000 rounds absolute minimum. Step 2: no! once you have a strong derived master key, you don't need to apply PBKDF2 on any keys derived from this master key. You are just wasting ...

4

What you are asking appears to be 'is AES commutative'? The short answer to which is no: encrypting with AES with key 1 then key 2 will not (generally) give the same output as encrypting with key 2 then key 1, which is what would be required for naive implementation. However, there are modes in which AES can be used which would be commutative. For example, ...

4

You could be able to reduce the space required for a meet-in-the-middle attack, if you follow a similar idea as the application of Grover's algorithm on collisions. Suppose you have two layers of $n$-bit encryption: Partition the inner keyspace into $2^{n/4}$ parts of size $2^{3n/4}$. For each partition generate the inner encryption table. Run Grover's on ...

4

Since you are deriving the key from a password, there is generally not a security advantage to using multiple encryption in the way you described. The entropy of key material generated is less than the maximum security provided by AES, which means an attack on the password will be more effective than a generic key recovery attack on the cipher. A ...

4

Yes, in case of VeraCrypt there is a difference, but it is negligible in practice. First we need to consider how VeraCrypt actually performs the cascading of the encryption algorithms which is (literally) a block-wise chaining. E.g.: $$C=E_{XTS}^{1}(E_{XTS}^{2}(E_{XTS}^{3}(M)))$$ where each $E$ is a block cipher run in XTS mode and all using the same XTS ...

3

The actual security would probably be about 65 bits. A meet-in-the-middle attack can be used to find the keys of both ciphers in less time than naive brute force. The attack would decrypt the ciphertext with all the 64 bit l keys of the outer cipher, encrypt the plaintext with all the 56 bit keys of the inner cipher, then look for matches. It only requires ...

3

What you propose is called Double Encryption. With two independent keys, it is vulnerable to meet-in-the-middle attacks as described in another comment. I just add that this attack can be performed almost memoryless. Details are in the answer to similar question about Double-DES.

3

Start with “Shamir's Secret Sharing” concepts… Abstract. In this paper we show how to divide data D into n pieces in such a way that D is easily reconstructable from any k pieces, but even complete knowledge of k - 1 pieces reveals absolutely no information about D. This technique enables the construction of robust key management schemes for ...

3

Does re-encrypting the same value with multiple keys reduce security? The answer is "it depends"; there are some attack models and encryption methods where the security is reduced, there are other cases where there appears to be no security reduction. Let us go through some models where we actually see a security reduction: Plaintext guessing attack ...

3

In general (especially without knowledge what encryption you consider), it's not possible to detect "correct decryption of one layer", if that's all you have and this "middle ciphertext" is not in a specific format. However, from today's point of view this is almost entirely irrelevant, because stronger attacks are considered: Kerckhoff's principle states ...

3

Your first option: Encrypted(Input) = AES256(key2, Serpent(key1, Input)) suffers from a textbook meet-in-the-middle attack. It only gives you one additional bit of security over AES alone / Serpent alone. Not a good choice if you're aiming for extra paranoia.

3

This is not a complete answer but it seems to me that it cannot be more secure than the original AES since otherwise it would mean that there is a serious weakness in the AES key schedule As far as being as secure there's at least one application in which it's a weakness : when you use AES inside a Davies-Meyer construction. An attacker has then more power ...

3

Yes, you can reasonably expect that these will provide equivalent security, if you choose all keys uniformly and independently at random. The decryption operation is basically the same as the encryption operation, so it would be extremely surprising if there was any significant difference in security among these. (Of course, if you don't generate the keys ...

3

There is a very simple, completely generic solution, that unlike the other solution doesn't assume anything about how the two encryption schemes work internally (e.g., that they are built from block ciphers or have pseudorandom ciphertexts): given a message $m$, choose a uniformly random $m_1$ of the same length and let $m_2 = m \oplus m_1$. Then encrypt ...

3

If you're using a real encryption scheme then no it cannot weaken or strengthen the system because the encryption scheme's security is supposed to be independent the actual data being encrypted. The plaintext could be random bytes or all zeroes for all it cares, it will be just as secure. All this modification achieves is lower your encryption scheme's ...

3

There's quite a few things wrong with this. For starters, a block cipher does not imply authentication. Common block cipher modes such as CTR, CBC, and (god forbid) ECB provide nothing but pure encryption. If you want authentication, look into the GCM block cipher. AES-GCM is possibly the better way to go here. You state that it is built on the idea that ...

2

Block ciphers are already built of multiple components: AES = fixed 8-bit sbox, MDS matrix multiplication, 8-bit rotations Twofish = key dependent sboxes, MDS matrix, 1 and 8-bit rotations, PHT Chaining ciphers adds more components, more rounds, more complexity Depending on chaining implementation, a different IV is not required for each cipher. For ...

2

Short answer: (Probably) yes. Long answer: DES is a Feistel cipher, and therefore encryption and decryption are almost the same process. The only difference is the reverse order of the subkeys. There are theoretical attacks on DES, which might have to be adjusted if you use reverse order of subkeys for encryption. If these attacks target the subkeys ...

2

To begin with 4: Remember Kerckhoff's principle. You should always assume that the attacker knows which algorithm is used to encrypt your data. All the algorithms used in practice are designed to be secure under this assumption, so you should consider that hiding the algorithm from the attacker is superfluous. But as a hypothetical... I can't think of any ...

Only top voted, non community-wiki answers of a minimum length are eligible