Tag Info

Hot answers tagged

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


3

AES is not provably secure, for the simple reason that there is no security proof for it. We suspect that AES is secure in practice, but there is no proof 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 ...


2

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.


2

The answer by Paŭlo 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 ...


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


2

I think you meant brute force when you mention, it would take trillions(?) years to break AES. So your "provably secure" category boils downs to brute forcing the algorithm which is not considered "breaking" the algorithm. AES is kind of a successor to DES (at least for an initial understanding) which had been in use for quite a long time and was not broken ...


1

Usually FPE is $Rank-LPE-DeRank$ Where LPE is length preserving encryption. The advantages of FPE schemes Preserving Formats and Lengths could be used against it too. There are two attack vectors specific to FPE (but they are by design !) Length Preserving This might aide to brute force attacks if the domain is too small. For example encrypting an IP ...


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


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


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


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



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