Tag Info

New answers tagged

1

To simulate $n$ times iterated ECB encryption, you can set your input plaintext block as the IV, encrypt a "plaintext" consisting of $n$ all-zero blocks using either CBC or CFB mode (which are identical for all-zero plaintext), and take the $n$-th block of the resulting ciphertext (discarding the rest of the output). Note that, if your CBC mode ...


2

First lets acknowledge this is a horrible hack - you really should find a way to do what you want more directly or risk code maintenance issues and likely bugs in the future. Second, while the question isn't about your key strengthening step it seems like you should ask about the security. There are lots of good key derivation methods out there and I don't ...


-1

It depends on your definition of secure. What most experts agree on is that ECB is a bad idea. The wiki page actually provides a pretty solid overview http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation


-1

As @Guut Boy mentioned it, ECB isn't semantically secure, in the sense that if a message with identical blocks is encrypted, then an attacker get a certain advantage to have information on plaintext, by only observing CipherText. Use preferably CBC mode to encrypt long message. This mode introduce an additional parameter called the IV (Initial Value), you ...


22

Why shouldn't I use ECB encryption? The main reason not to use ECB mode encryption is that it's not semantically secure — that is, merely observing ECB-encrypted ciphertext can leak information about the plaintext (even beyond its length, which all encryption schemes accepting arbitrarily long plaintexts will leak to some extent). Specifically, the ...


14

You should not use ECB mode because it will encrypt identical message blocks (i.e., the amount of data encrypted in each invocation of the block-cipher) to identical ciphertext blocks. This is a problem because it will reveal if the same messages blocks are encrypted multiple times. Wikipedia has a very nice illustration of this problem.


7

One obvious thing that it is vulnerable to a known plaintext attack that truncates the known message. This attack is quite simple; suppose the attacker knows a message $(P_1, P_2, ..., P_n)$ and the corresponding ciphertext $(C_1, C_2, ..., C_n, T)$ (using some IV; we don't care what it is). Here is how the attacker can generate a ciphertext that would ...


1

I believe that, in this specific case, you are correct; it would appear to take $2^{60}$ effort to find a collision in the above function. On the other hand, there is one nit with this approach: this makes stronger assumptions on the block cipher than is typically assumed. A block cipher behaves as a random permutation if it is keyed by a random unknown ...


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


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


1

Rijndael-128, Rijndael-192 and Rijndael-256 are actually 3 different variants of block cipher that are very similar. Simon, Speck, Threefish and RC5 also define different block size variants in similar way. Rijndael is not unique in this regard. Block cipher that really has variable block length is XXTEA as its block length is not limited.



Top 50 recent answers are included