# Could a larger block size increase the security of the block cipher?

I want to know if a larger block size increase the security of the block cipher?

• This might be helpful: crypto.stackexchange.com/questions/6016/… – hunter Jun 24 '17 at 12:32
• It very much depends on the details of the implementation, blocksize isn't just another tunable parameter as you may know it from mathematics. For example take any standard block cipher. Now treat the first few bits as normal using the normal block cipher call and leave the rest untouched. Obviously this "block cipher" doesn't have increased security. – SEJPM Jun 24 '17 at 15:02

TL;DR: a larger block size won't help to make the block cipher itself more secure, but it can be used to make the schemes using the block cipher more secure.

The block size basically determines the number of possible permutations: the possible ways to combine all the possible plaintext blocks with the possible ciphertext blocks. The number of permutations grows much faster per bit of the block size than the number of possible keys from the key size. In that sense it is unlikely that a larger block size will do much for the security of the cipher.

Modes of operation however do rely on the block size for other purposes. For instance, the counter size of AES-CTR is defined to be the same size as the input block size. That counter usually consists of a random nonce and a counter part, for instance 64 bits for the nonce and 64 bits for the counter. However 64 bits is not that much for a nonce; as the birthday problem applies you can only encrypt about $2^{32}$ ciphertext before the counter could repeat. Now this isn't a huge problem, but it would be avoided with a block size of 256 bits (or, indeed a tweak, or both).

Specific constructions could also require a larger block size. For instance a hash function generally relies on large state. To go from one large state to another a block cipher could be used. Obviously it would need to have a large state and a large block size itself. There are other ways to do this with a cipher with a smaller block size but it won't be as efficient.

There is most likely no need or win to go beyond 128-Bit (16byte) block sizes as used by most modern ciphers (for the Rijndael algorithm the 192 and 256 bit block sizes did not make it into the AES standard as it was deemed unnecessary).

However older 8byte ciphers are vulnerable because of the limited blocksize. The problem here is that collisions due to birthday paradox are quite likely.

this is known as the SWEET32 problem, see for example sweet32.info. It is especially a problem for network protocols with streaming data. This is the main reason why blowfish is no longer considered secure for encryption.

NB (since some comments state otherwise) This weakness is pretty much independent of the actual cipher used.

• This is actually incorrect. It was a big mistake to not certify larger block sizes for Rijndael. Case in point: if you use CTR with a 96-bit IV and maximum block size 32 bits (as is standard), then you already go beyond good security bounds after encrypting $2^{32}$ messages. Although this all sounds like a lot, there are cases where this happens. – Yehuda Lindell Jun 25 '17 at 7:05

To really answer your question, you need to address the way in which the block cipher will be used.

Let's consider the block cipher mode, for example. If I use AES in ECB mode, it doesn't matter if I use AES-256, AES-4096, or AES-65536. Your security posture is annihilated.

You haven't specified any particular use-case, so the best answer is: Not necessarily / It depends.

Warning: you may hear claims by marketers of various security products stating that they are using "military-grade encryption" and will boast a large block size ("oh my goodness, AES-8192 is way better than that AES-256 everyone else uses!"). Don't be seduced by such claims. Caveat hackor.

• There is no,AES-4096 and for all AES key sizes the blocksize is the same 128bit. Also ECB is fine for short messages. – eckes Jun 24 '17 at 20:33
• ECB is not fine for short messages! – Elias Jun 24 '17 at 20:47
• It's fine if they are unique and short than one block. Which ismactjally quite common (think key wrapping) – eckes Jun 24 '17 at 20:52
• Schneier, 1993, Applied Cryptography: "ECB is a good mode for short random messages." Schneier, 2010, Cryptographic Engineering: "Do not ever use ECB for anything." – user47922 Jun 24 '17 at 20:53
• You mix up key- and blocksize. – eckes Jun 24 '17 at 20:53

Ceteris paribus. All things being equal then clearly the block size affects the cipher security. That's why we're not using 32 bit Skipjack ciphers any more. It increases the brute force effort to break and reduces the probability of block collisions. Incidentally the same is true for hash functions. This issue that slightly clouds the block width comparison is that a newer and wider block cipher tends to be a rewrite from scratch. So AES <- DES and a direct comparison cannot easily be made.

A slight caveat though is that a cipher with a 2048 bit block size appears be just as impossible to brute force as a 256 bit cipher. This begs the question when is the block width adequate? AES' 128 bit block width seems to be holding up presently to attack, although it's anyone's guess how long this situation will last.

And now the cynicism and speculation. AES' owes it's existence to US government policy. It's unlikely that a 2048 bit cipher will be developed within the foreseeable future without that same governmental support. It's not inconceivable that a new competition could be launched for a server level only cipher based on a 2048 bit block width.

• I'm not sure the block width matters as much as you think it does. A larger block size reduces diffusion, so simply using bigger and bigger blocks does not increase security. And the only issue with small block sizes is when they're used in particular modes of operation where a larger size makes it effectively immune from practical attacks. Though wide-block modes (like EME2 and XCB) are useful for disk encryption... – forest Dec 31 '18 at 3:35