# Tag Info

1

General descryption The block cipher is an operation that lives in the box [block cipher encryption]. A block cipher can do two things: encrypt and decrypt. It is parametrized by a key, which is one of two inputs. The other input is a block of data. The output is the keyed permutation of that block of data. A permutation is a 1:1 relation; each input block ...

1

DES would be the box in your diagram that's labeled "Block Cipher Encryption", and it participates in the encryption mode you show in two ways: the output is XORed with the plaintext, and the output is used as the input to the next block's use of DES (the second "Block Cipher Encryption"). In this mode, you're using DES to generate a sequence of random ...

1

If the attacker can make related-key chosen-plaintext queries, then there is a generic attack that can break any block cipher with $n$-bit keys in $2^{n/2}$ time, using $2^{n/2}$ related-key queries and $2^{n/2}$ memory. So against a related-key attacker, the effective strength of a block cipher can be no more than half the key length. However, the ...

0

Your question here has two answers, depending on what you mean. The first is the distinction between birthday attacks and exhaustion attacks. In a birthday attack, the attacker wins if he gets two messages that have the same key. And in that case the security is proportional to half the key length. In an exhaustion attack, the attacker has a specific ...

0

It really depends on the key schedule. IE, how is the key operated on to find the permutation to be used? Absent that knowledge, really the only way to know is to launch searches in parallel at different key lengths, and the one that finds the answer first had the right key length. Unfortunately anything more clever than that will utterly depend on how ...

1

The accepted answer is completely wrong. There is a simple way to convert a stream cipher into a block cipher. In pact, it works for any PRF, regardless of if it is reversible or not. This presentation perfectly covers how to use a PRG such as a stream cipher to construct a block cipher. Basically, you use the stream cipher in the following manner: Take ...

0

Most stream ciphers (the so-called synchronous ones) work by producing a key stream from a key, which is then XORed with the plaintext to produce a cipher text. It is important that the same key (or, equivalently, the same part of a keystream) is not used twice, as then it is (more or less) easy to recover the plaintext. If you use only a small part of that ...

3

Anon2000 - as currently constructed your mode is fatally flawed. Given two known messages encrypted with the same key (i.e. where the attacker knows the plaintexts) that are each at least two blocks in length (not counting the IV or final validation block), the attacker can trivially forge at least two other 'valid' messages (and many more than that if the ...

1

This does not meaningfully authenticate the ciphertext. Your encryption is the same as OFB, meaning no block depends on the previous plaintext; for instance, $$C_2=P_2\oplus E(P_1\oplus (P_1\oplus E(IV\oplus 0)))=P_2\oplus E(E(IV)).$$ That means confidentiality should be fine; however, it provides no authentication except of the length of the message.

1

Consider what would happen if an attacker altered one of the ciphertext blocks, but kept the IV and all previous ciphertext blocks identical. i.e. Xor some difference $\Delta$ to ciphertext block $C_x$, so that the altered block $C''_x = C_x \oplus \Delta$. This will produce an altered corresponding Plaintext block, like so: P''_x = C''_x \oplus ...

0

An alternative solution using one encryption, one cryptographic hash and one (possibly fast) non-cryptographic pseudorandom number generator operation per block. Encryption: Take the last plaintext block, and use its value (or some part of it), to seed a (possibly non-cryptographic) random number generator (note it could be XORed with the key for added ...

0

Let $H(m)$ be any strong hash function. Since you want to use encryption only, we'll specify that $H(m)$ = $E_{key}(m)$ where $E$ is a 128-bit block cipher. We're trying to create an encryption mode that will cause any change to the ciphertext to propagate over all blocks of the plaintext. Strategy is to do two passes over the message, first forwards, ...

1

Will this method deliver true non-malleability? No. If we set the ciphertext to the value $(B, B)$, then the decrypted plaintext will have the second block as $B$ (assuming that the PCBC mode uses an implicit plaintext/ciphertext IV of 0; if it's two known constants, it's easy to adjust for that). Even if we ignore this, it also fails to make sure ...

1

Anubis (128-bit block) and Khazad (64-bit block) work by using involutional components in sequence. The complete ciphers are not fully involutional, as the key schedules and round constants prevent that from occurring. Decryption requires a different key schedule, but all other operations remain the same. They are SP-network ciphers, which are generally not ...

0

You can turn any secure $n$-bit pseudorandom function into a secure(?) reciprocal $2n$-bit block cipher by using the former in a Feistel network of at least 4 rounds with a palindromic key schedule. (?) I'm not certain whether the Feistel construction is weakened by a palindromic key schedule, so I'm hesitating to call it secure.

2

The way i see it, given no context, is that indeed a block cipher is deterministic, i.e. the same message will always be mapped to the same ciphertext. Therefore block ciphers itself are semantically insecure, as ciphertext indistinguishability isn't met. You might want to check http://en.wikipedia.org/wiki/Ciphertext_indistinguishability for further ...

8

That statement is ambiguous, so I'll list a couple of limitation of block ciphers and cryptography in general: A raw blockcipher by itself only permutes a fixed size block (128 bits for AES). You need to add a mode of operation (together with IVs and possibly padding) to make it flexible enough for practical use. There are many modes to choose from, ...

0

Without context i would say the following: It is true, if you have a message bigger than the block cipher every same block will be encrypted to the same ciphertext making it quite insecure. I simply think this statement is used for the promotion of modes of operation

1

There's a lot of ways to attack this. The first thing to notice is that if you know the value of plaintext at index $i$, you can then deduce the value of all the plaintext bytes at index $i+8k$; for all integers $i$ (!). That's because the relation between plaintext and ciphertext bytes is $P_{i} = C_{i} \oplus P_{i-8}$; if you know $P_{i-8}$ (and, of ...

Top 50 recent answers are included