Can anyone shed some light onto the advantages/disadvantages of using Rijndael with 256-bit block size, as opposed to the 128-bit (AES) implementation? (please note: I'm not referring to key-size here).

These are standard implementations in Mcrypt. I'm vaguely aware that a larger block size can help to mitigate some kinds of attacks... is that true? Which ones? Could a larger block size also introduce weaknesses? I'm just curious to know why the 128-bit version become the standard, and whether there's any good reason to use the 256-bit version.


1 Answer 1


I'm just curious to know why the 128-bit version become the standard[.]

That question is easy to respond. In the section Minimum Acceptability Requirements of Request for Candidate Algorithm Nominations for the AES, it says:

The candidate algorithm shall be capable of supporting key-block combinations with sizes of 128-128, 192-128, and 256-128 bits. A submitted algorithm may support other key-block sizes and combinations, and such features will be taken into consideration during analysis and evaluation.

So, while supporting different block sizes is considered a desirable property, AES's block size was already decided before the competition even started, i.e., it has nothing to do with the Rijndael algorithm itself.

I'm vaguely aware that a larger block size can help to mitigate some kinds of attacks... is that true? Which ones?

For some attacks, yes.

Some block modes of operation (e.g., CBC) require that the same ciphertext will never get generated twice. If $$E(C_1 \oplus P_1) = E(C_2 \oplus P_2)$$ ($P_i$ denotes a plaintext block, $C_i$ the previous ciphertext and $E$ the encryption function), since $E$ is bijective, $$C_1 \oplus P_1 = C_2 \oplus P_2,$$ and, therefore, $$P_2 = (C_1 \oplus C_2) \oplus P_1.$$

Since $(C_1 \oplus C_2)$ is known by design, if you know $P_1$ as well, you can derive $P_2$ (see: code book attack).

With a block size of $n$ bits, collisions become likely after roughly $2^\frac n2$ blocks of plaintext (see: birthday problem). This was a problem of DES (with a block size of 64 bits, $2^{32}$ blocks are only 32 GiB of plaintext). A block size of 128 bits ($2^{64}$ blocks are 256 EiB of plaintext) should be enough for the foreseeable future.

The same concern applies to other block modes of operation (e.g., CTR) as well, although it is not as easy to launch a successful attack. After roughly $2^\frac n2$ blocks, collisions should start to occur. However in CTR mode, $E(nonce+counter)$ won't produce any collisions in the first $2^n$ blocks. Therefore, the stream will become distinguishable from a random stream at a given point (see distinguishing attack).

Could a larger block size also introduce weaknesses?

In general, yes.

Despite its simplicity, the cipher XTEA remains unbroken. However, its extension Block TEA (XTEA is Block TEA with a block size of 64 bits), is vulnerable to differential cryptanalysis (see: A Cryptanalysis of the Tiny Encryption Algorithm).

I'm just curious [...] whether there's any good reason to use the 256-bit version.

Categorically no!

In AES proposal: Rijndael, the authors say:

For Rijndael versions with a higher block length, the number of rounds is raised by one for every additional 32 bits in the block length, for the following reasons:

  • For a block length above 128 bits, it takes 3 rounds to realise[sic] full diffusion, i.e., the diffusion power of a round, relative to the block length, diminishes with the block length.

  • The larger block length causes the range of possible patterns that can be applied at the input/output of a sequence of rounds to increase. This added flexibility may allow to extend attacks by one or more rounds.

Furthermore, the authors recommend a number of round ($Nr$) of $$Nr = max(Nk, Nb) + 6,$$ where $Nk$ is the key size and $Nb$ the block size (both in 32-bit blocks).

This means that Rijndael-128-256 will be slower than Rijndael-128-128 (AES-128), and that Rijndael-256-256 may have a lower security margin that Rijndael-256-128.

Bottom line

Rijndael N-256 hasn't received nearly as much attention as AES, so it might have some undiscovered weaknesses.

In contrast, AES is considered secure, despite being subject to probably more cryptanalysis than any other cipher.

The 128-bit block size isn't a problem. If it ain't broken, don't fix it!

  • 2
    $\begingroup$ At least it isn't a problem for encryption. If you wanted to build a hash function from AES (theoretically speaking - in real life you don't do that and use a primitive designed to that end) you'd need to pick a high rate compression function to compensate for the small block size. $\endgroup$
    – Thomas
    Commented Jan 18, 2013 at 5:20
  • $\begingroup$ It isn't much of a problem with most modes of encryption. But you could argue that it is rather minimal when it comes to CTR (and therefore other modes based on CTR): 64 bit isn't all that much when it comes to random nonces and if you increase the nonce size you'd have less than $2^{64}$ blocks to include in a ciphertext. With a nonce of 128 and a counter of 128 you would not have to worry at all. $\endgroup$
    – Maarten Bodewes
    Commented Feb 2, 2017 at 13:18
  • 2
    $\begingroup$ "Realise" is just not American English, but it is still the proper spelling in much of the English-speaking world. It's not a typo. $\endgroup$
    – forest
    Commented May 2, 2018 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.