Tag Info

Hot answers tagged

12

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


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.


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

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


4

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


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

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


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

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


2

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.


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

In short: does storing these encrypted files in an encrypted partition/folder create the same potential weaknesses as cascade encryption? If not, what of encrypting a .tar of encrypted documents? An encrypted file inside an encrypted container is a cascade of ciphers, almost by definition. Is that a problem? Not really. A cascade of ciphers shouldn't ...


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


1

Two things to consider: encryption and authentication. In general you can only say that a cascade of ciphers is as secure as its weakest link. If the encryption in NaCL had a side-channel attack, it might leak information about the plaintext, whether or not the ciphertext is sent through TLS. Authentication, on the other hand, is additive. If you can ...


1

If you have a secret key (256-bits) shared between the two systems that see the entity identifiers, you can use HMAC-SHA256 to map entity identifiers to a random string. Under the assumption that HMAC-SHA256 security is good (which is widely believed to be a reasonable one), this is just as secure as having generated a truly random mapping, but requires ...


1

If by "encrypted" you mean generating a keystream, then what you propose is to use in the CTR mode $$ C_i = P_i \oplus F_K(IV||i) $$ the following function $F$: $$ F_{K_1||K_2||K_3} = E_{K_1}\oplus E_{K_2} \oplus E_{K_3}. $$ This is secure as long as you ensure that for each key all the used IVs are different (i.e. are nonces). As mentioned in another ...


1

You asked several questions above. I will address one in specific that stands out to me, and that is your question about XORing the keys together. Your statement that they might both have the same character at the same location that would yield a null byte is disconcerting: passwords are not normally used directly as encryption keys. Mathematically, a ...


1

It really depends on what sort of break AES would suffer. The primary issue with DES was that it's key length was too small (56-bits). Multiple encryption can help here because it increases the effective key length of the whole operation. The meet-in-the-middle attack on DES takes about 2^112 operations, which is infeasible to brute force anytime soon. AES ...



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