# What problems might you encounter if you use a block size much greater than AES?

What problems might you encounter if you use a block size much greater than AES (1000 bits, say)?

• Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big – kelalaka Dec 2 '18 at 21:57
• Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me. – lyrically wicked Dec 4 '18 at 6:48

It may be very tricky to have a good distribution / diffusion of the input bits for each round. That would mean that you would either require a very intricate design for each round, or a lot of rounds to make up for it.

Furthermore it will also mean that you need to perform an operation of at least 1000 bits to perform any kind of calculation. This is not a desirable property in most circumstances. For some modes of operation such as CBC, it will mean that the minimum message size would be 1000 bits - and the IV would take up another 1000 bits. For counter (CTR) mode your message will not grow as only part of the output can be used. However, that still means doing 1000 bit calculations for possibly much smaller messages.

Most modes of operation function quite well for block sizes of 128 bits, although 256 bits would be beneficial for modes such as CTR (because the IV is split between a nonce and the counter).

Although a large block size is desirable for use in the design of hash functions, the avalanche effect does require a good diffusion of bits. Threefish - the block cipher used for Skein, one of the SHA-3 finalists - however does support a block size of 1024 bits, so ~1000 bits is certainly not unheard of (quite often the internal hash state is at least double the intermediate / output size). Skein 512 however requires 80 (!) rounds of Threefish1024 so it certainly wasn't the fastest algorithm out there.

A relatively fast large block cipher may also be beneficial for some format preserving encryption, by the way. In principle a single block encrypt of a unique value is secure, so having a large block size may be helpful avoid repetition of blocks. You could build a cipher with a larger block size from a block cipher with a small block size, but those kind of constructs are generally not all that efficient.

• Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet. – Maarten Bodewes Dec 3 '18 at 9:07
• It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds... – lyrically wicked Dec 4 '18 at 6:49
• Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec". – Maarten Bodewes Dec 4 '18 at 14:49

This problem has been studied and comes under wider block-cipher encryptions, examples are Mercy block cipher , Bear and Lion , and Simpira. My answer ties with Simpira block cipher case. Simpira has been recently developed to work on 64 bit processors (v2 is also available) which uses 128 bit x b , where b is a positive integer.

Simpira is a cryptographic permutation that combines AES and Feistel structure. In Simpira cipher , the number of rounds required to achieve full diffusion increases along the b value , (12,15,21 rounds for b=1,2,3).This means , to achieve full diffusion of wider size more rounds are required therefore performance will downgrade.

for further information: Simpira