# Tag Info

9

ECB leaks if blocks are identical. For uniformly random data identical blocks become likely when you encrypt about $2^{n/2}$ blocks with an $n$ bit block cipher. CBC and CTR mode develop similar weaknesses when they encrypt that much data. => As long as you encrypt reasonable amounts (up to a petabyte or so) of random data with a 128 bit block cipher, like ...

4

I should begin by noting that this seems like an unusual assignment. I'm not sure why someone would explicitly have a goal of combining block ciphers and stream ciphers. First, let's summarize the difference between block and stream ciphers, since this may be useful for future readers. Block ciphers are so called because they operate over fixed lengths of ...

3

The size of the key depends on the security level you want, it is not possible to say "you need exactly $n$ key bits if you have a block size of $m$ bits". Let's assume that for an ideal cipher, a block size of 32 bits means $2^{32}$ possible input values which can be permuted in $(2^{32})!$ ways. That means you would have at most $\log_2(2^{32}!)$ key ...

2

Key generation and key scheduling are different things. The key scheduling is part of the cipher, the key generation generally isn't. Symmetric keys should be indistinguishable from random, so often they are the product of a secure random number generator. There are other ways as well, such as derivation from a password using a Password Based Key Derivation ...

2

Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations. Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on ...

2

A few approaches: Generic format preserving encryption. For example AES in FFX mode. The downsides of this approach are complexity and performance. Block-ciphers with small (typically 32 bit) blocks. Skip32 derived from Skipjack ipcrypt (very recent, no security analysis so far) The downside of this approach is that these ciphers aren't very popular ...

2

AES-CTR is very appropriate. Since a credit card number is 16 characters long, it can be encrypted using a single 128-bit block without any encoding. You will only need 1 block, and hence not require a block counter, just the nonce. Depending on the amount of card numbers being stored, you would only need to store a portion of the full nonce. A 32-bit ...

2

swap-or-not seems perfect for your use case.

1

You can't parallelize decryption. You can only paralellize encryption. Now encryption happens much less often than decryption and hence a parallizable decryption is not good. (especially for full disk encryption) Plaintext isn't random. In most cases an attacker can predict plaintext. As you basically use plaintext as IV for each block you make the scheme ...

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