Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

# Tag Info

29

This is simply saying that if a cryptosystem has a functional composition that is $$h_{k}(x) = f_{k_1}(g_{k_2}(x))$$ then you can find a key for single encryption that works as the double encryption. For example: consider the permutation cipher where a permutation is a key. The permutations are forming a group, named permutation group, under the ...

25

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

13

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

13

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.

12

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

9

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

8

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

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

No, If we assume that the mythical computer can brute force the multiple AES encryptions and there are many ciphertexts available which are encrypted under the same key and their corresponding plaintext are not random. The brute-force code can keep track of the meaningful plaintexts for each ciphertext and finally can perform an intersection of possible key ...

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

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

5

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

5

Yes, systems that allow this have a name: commutative encryption. In practice, there are two varieties: If A, B, C just xor in a keystream, it all commutes. Of course, anyone seeing the intermediate results can deduce quite a lot; this may make this unacceptable for some uses. Pohlig-Hellman (not related to the Pohlig-Hellman algorithm); we pick a global ...

5

I'm not sure what the question here is, but obviously applying the hash function twice can never decrease the number/probability of collision as all collisions in the first invocation are maintained. However if H is collision free( a permutation as opposed to a random function) doubling will not cause any more collision it will remain collision free. So we ...

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

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

4

Maybe this example is only remotely related to the question, but anyway: VeraCrypt application for encrypting computer's disks has an ability to offer part of the disk capacity to reach the plausible deniability with the help of 2 different passwords: the first one unlocks so called outer volume with a non-important content, the second one unlocks inner, ...

4

This is precisely the domain of secret sharing, of which there are various popular schemes like Shamir's secret-sharing scheme, and there are many widely available implementations of it in various forms which you can find with exactly those keywords.

4

The answer is we cannot improve the security of the one-time pad in this manner. Intuitively the reason is that the double one-time pad is just a less efficient one time pad. The security of the traditional xor-based one-time pad is requires that the key $K$ is chosen uniformly at random for each message and that the key is at least as large as the message. ...

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

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

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

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

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

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.

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