Tag Info

Hot answers tagged

13

Decrypt the ciphertext with every possible key and store the result: $2^{56}$ decryptions. Now encrypt the (known) plaintext of the ciphertext with every possible key: $2^{56}$ encryptions. Now you have to check every entry, which is in both lists and try it with another plaintext-ciphertext pair. If you can successfully decrypt that, you are very likely to ...


9

Re-using their design might be no good idea - there are cheaper designs for sure. This new DES cracker would just need to try every possible key - like the one of the EFF already did. DES was a big standard for encryption, so some people did build such machines, right? Of course did they: COPACOBANA is able to break DES in under 9 days and costs under ...


7

In computer science, and implementation of crypto, ROTL stands for ROTate Left. ROTL is also noted ROL, or RLNC for Rotate Left No Carry. On a $w$-bit word with bits numbered from $0$, bit number $j$ of the input of ROTL with a shift count of $n$ goes to bit $j+n\bmod w$ of the result; $n=1$ unless otherwise specified (and is the only value available on ...


7

DES is slow in software because it was designed back in the early 70's even before the 8086 processor existed, and uses several bit oriented operations that are just not implemented efficiently in a processor with a word oriented instruction set. Its intended product was ASIC hardware designs, in which DES runs quickly. DES hardware processors are quite ...


6

No, that is impossible. The reason is simple: How would you decrypt this? If you input the ciphertext and the key into the decryption function, than you have to get exactly one output, not two. How would you decide which output is the correct one? The DES encryption and decryption functions are bijective under one given key. This means that for every ...


6

DES with 2 rounds is broken. It is trivial to find a way to get the key with much less work than for the full DES (and even that is broken). DES is a Feistel cipher, so we have two halves, the left and the right half. For every round, we do something with the one half and a subkey, and then XOR it with the other half. After that we switch both halves, ...


6

DES is slow compared to AES including in hardware because for comparable security we must use 3DES, which triples the number of rounds per block, to 48 for 3DES versus 10, 12, or 14 for AES; DES's block size is 64 bits, half of AES's 128 bit; so when encrypting a sizable block of data, 3DES does more rounds that AES by a factor of 96/10, 96/12, or 96/14; ...


5

I add my whitebox AES implementation on GitHub in: C++ Java C++ version implements both Chow's (mixing bijections, input/output encodings, external encodings) and Karroumi's (dual AES in each column) whitebox AES scheme plus Billet's key recovery attack on both schemes. Java implements Chow's scheme only. PS: Due to low reputation I post links to ...


4

Yes, it would be more secure if they were used correctly. But as it would require a substantially different algorithm, you really would not be talking about DES anymore. Brute forcing usually scales exponentially with the size of the key. However, if the algorithm is substantially altered then it is required to analyze the algorithm again. Note that AES is ...


4

If you mean DES as block cipher without mode of operation then no, this is impossible. DES is a block cipher, and block ciphers are Pseudorandom Permutations (PRP). As permutations in turn are bijective functions of $\{0,1\}^n$ to $\{0,1\}^n$ there is always a one to one relationship between plaintext and ciphertext. If this wasn't the case then you would ...


3

Yes, it can; within the DES round function, two different 'right side' inputs can, after the sboxes, come up with the same value to xor into the 'left side'. This was a deliberate decision by the DES designers, who thought that this was an important property. I don't know their reasoning about why they thought it was important.


3

It looks like there's an error in the test vector. The text of Appendix B.1 states: P1 = “The quic” = 5468652071756663 ... which is incorrect. The hex encoding of The quic is actually 5468652071756963 (note the transposition of the i/69 to an f/66 in the encoding. e.g. encrypting the test vector as intended: $ echo -n 'The quick brown fox jump' | ...


3

Actually, because of DESX works, the meet-in-the-middle attack can be optimized to take $2^{119}$ $DES$ (and no $DES^{-1}$ operations), and no additional storage. Here is how it works: let us assume that we have three known plaintext/ciphertext pairs $(P_1, C_1)$, $(P_2, C_2)$ and $(P_3, C_3)$. We know that: $$C_1 = K_2 \oplus DES( K, K_1 \oplus P_1 )$$ ...


3

You cannot encrypt 720 bits plaintext using just AES-128. AES is a 128 bit block cipher. Such a block cipher has an input of 128 bits of plaintext and an output of 128 bits ciphertext; and that's it. You need some kind of construction to make block ciphers encrypt larger or smaller plaintext. Such constructions are known as (block cipher) modes of ...


2

According to the following link (Slide 5) and to what I studied last semester, http://www.ee.ic.ac.uk/pcheung/teaching/ee4_network_security/L02DESIDESAES.pdf During the final round (Round 16) before the inverse permutation, the left and right halves of the bits will be swapped then the inverse permutation will be applied.


2

This is known as the "key complementation" property of DES; I had thought that it actually predated Biham and Shamir's work. In any case, your questions: Does this hold for only that particular combination of s box or it will be same for any S-box combination It'd remain even if you change the sbox's arbitrarily. The reason for this is that it is not ...


2

The key space for DES is far too small (56 bits). Therefore, any use of DES is not secure. It doesn't matter what mode you use. If the attacker has one plaintext, ciphertext pair, they can brute force the key space and recover the key in a feasible amount of time (24 hours using the cloud). But most importantly, how it could be made secure? Will change ...


2

I understand that if a block cipher has $k$-bit keys and $n$-bit input/output blocks, then if $k>n$, we can expect one message-ciphertext pair to narrow us down (I think?) to $2^{k−n}$ possible keys, right? That is approximately correct (if the block cipher with the wrong key acts like a random permutation; this is generally a safe assumption); if ...


2

That's an optimization for the attack. It would work without it, but slower. To do a Meet-in-the-middle attack, we need to encrypt a known plaintext with every possible key and save the resulting text (with the used key) in a list. Now we decrypt a known ciphertext with every possible key and look if we got the resulting text in our list. We want to know ...


2

Feistel networks were broken in DES but not triple DES. Some final AES candidates not approved also used Feistel networks $2^{36}$ plain text attacks. Reduction of $2^{16}$ possible keys for single DES: $4^{48/6} = 4^{8} = 2^{16}$. First for a one round Feistel network: $R_0$ and $f (R_O, k_1) = R_1 \oplus L_0$, $k_1$ becomes known. For two round Fiestel: ...


2

In short, yes. The complementation property of DES states that if $DES_K(P) = C$, then $DES_{\overline{K}}(\overline{P}) = \overline{C}$, where $\overline{X}$ is the complement of a string $X$. ECB with DES takes a message $M_1M_2\cdots M_\ell$ and computes $C_1C_2\cdots C_\ell$, where $C_i = DES_K(M_i)$, for $1\le i\le\ell$. Therefore, if you encrypt ...


2

According to Wikipedia, GCM is defined for block ciphers with a block size of 128 bits. So no, you can't use GCM with 3DES or DES, because of the 64-bit block size. You could use something similar to GCM, but it wouldn't be GCM.


1

During CBC mode decryption, each ciphertext block is first decrypted with the block cipher, and then the first decrypted block is XORed with the IV, while later blocks are XORed with the previous ciphertext block: Thus, the first block of plaintext is computed as: $$P_1 = IV \oplus D_K(C_1).$$ Equivalently, we may solve this equation for $IV$ to obtain: ...


1

Including Parity bits absolutely does not increase the cryptographic strength of DES (or 2-key TDES, or 3-key TDES). The DES feistel network itself only accepts eight 7-bit blocks as input, no more and no less. You can add as many parity as you want, but that doesn't mean any more bits are being processed by the algorithm. Parity bits are either used ...


1

First, note that $192=3\cdot64$, so the real key length of 3DES is $192$ bits. However, since $8$ bits in each subkey are parity bits, this reduces to $3\cdot56=168$ bits of non-redundant key material. Now, the reason that 3DES' effective key length is usually classified as $2\cdot56=112$ bits is that 3DES is susceptible to a meet-in-the-middle attack: When ...


1

DES has been specified to take a 64 bit key, but only 56 of them are used. The remainder are parity bits. The key ostensibly consists of 64 bits; however, only 56 of these are actually used by the algorithm. Eight bits are used solely for checking parity, and are thereafter discarded. Hence the effective key length is 56 bits For 3DES the nominal key ...


1

Xor can help find bits not yet known, whether most significant or least significant; and help the adversary find more information about both ciphertext and plaintext, especially if a table of potential plain texts or even keys is stored in conjunction with bitwise Xor. Some reading: ...


1

It is for the 1st version of 3DES which is only using the same key three times (3DES-EDE1) Which is equivalent to DES (I think they did that so you could use 3DES to exchange with someone using DES). There are 3 different versions (or ways of using DES). EDE3 is the strongest with 3 different keys being used.


1

Note: you should also take into consideration the Expansion table, as it glues together with the Pbox. The simplest thing you would like to want from a Pbox is to provide a good diffusion on the inter-sbox level. That is, a single sbox should have an effect on many sboxes in the next round. This is not sufficient, for example you could have some indepent ...


1

You're missing a component : a padding convention. Yes, if you're trying to reduce a block size, it will reduce the cipher strength. That's why the less-sized blocks are padded/filled to fit the exact size. What to do : pad or fill or both - that is a question. First you need to understand, that the more predictible the message, the less secure the ...



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