2
$\begingroup$

Let's suppose someone creates a block cipher with 8192-bytes of the block size (65536-bits) or maybe 16384-bytes of the block size (131072-bits).

What would be its disadvantages over a block cipher with smaller block sizes like 128 or 256-bits?

$\endgroup$
7
  • 1
    $\begingroup$ Wouldn't fit onto an Arduino? $\endgroup$
    – Paul Uszak
    Mar 26, 2022 at 5:50
  • $\begingroup$ Let's say you have a 65536 bit block size & your plain text is 65537 bits or (65536*k) + 1 bits, then you would need to pad the last block with 65535 bits - which is a waste. Plus, I think large block sizes become inefficient $\endgroup$
    – user93353
    Mar 26, 2022 at 5:55
  • $\begingroup$ @user93353 That's an interesting point. One of the silly reasons that anti-paders come up with against one time pads is that it becomes difficult to encrypt a 12 TB hard disk. Yet you're suggesting that people might send small messages. A dichotomy? $\endgroup$
    – Paul Uszak
    Mar 26, 2022 at 5:59
  • 1
    $\begingroup$ @PaulUszak - Yet you're suggesting that people might send small messages - no I am not suggesting people may send small messages. Even if it's a large message but the message size is (65536*k) + 1 bits, the same padding waste happens. $\endgroup$
    – user93353
    Mar 26, 2022 at 6:48
  • 1
    $\begingroup$ @PaulUszak - there are other reasons for not using stream ciphers in FDE - crypto.stackexchange.com/a/53544/3941 $\endgroup$
    – user93353
    Mar 26, 2022 at 6:50

1 Answer 1

2
$\begingroup$
  • Padding issue: If one uses a block cipher mode like CBC, then they need padding, and remember that padding is always applied regardless of the size. Even if the size $65536*k$ then a new full block is required. It is not clear how one can apply the PKCS#7 padding since is supports up to 256-byte blocks. There are other easy paddings to apply like adding 1 then zeroes then encoding the padding size.

    In modern cryptography, we are away from padding modes, we are using modes like AES-GCM and ChaCha20-Poly1305 modes are paddless authenticated encryption modes.

  • Number of rounds: If we consider the Rijndael that requires an extra round per 32-blocks, a similar block cipher will require 2048 rounds to achieve the same level of security ( keep in mind that this is truly a rough estimation). This creates a latency for the first output. ~148 times slower than the first output of the AES-256. While this latency may not be important for messaging on Signal, there are places where the latency is not preferable.

  • Key size issue: In SPN, we use the key to x-or to the round values. If the key size is smaller than the block size, this is truly a security issue that may lead the linear and differential attacks new possibilities. Therefore, one needs to generate, exchange transmits, and store a key of size 65536 bits.

  • Implementation issue: while keeping aside the constant time implementation on the software, in the hardware such size will require more area to implement. This will increase the cost of the implementation and will require more power than smaller-sized block ciphers.

  • Message size issue: for shorter messages than the block size, this is very common in databases, if CBC mode is used, this will create a size issue. Yes with CTR-based mode one can mitigate this, however, one will spend more time to encrypt/decrypt than shorter block-sized ciphers.

  • Post Quantum: There is no advantage of this on post-quantum since AES-256 is already secure against Grover's optimal algorithm.


  • Do we have need larger than 128-bit block ciphers?

    Yes. For example, if AES was standardized exactly as Rijndael, then the random nonce issues of the AES-GCM will be no more issue for us. Random nonces of size 256 will be safe of collisions under the same key.

  • Do we have larger than 256-bit block ciphers?

    Yes, the CPU-friendly ChaCha20 that has a 512-bit output on the CTR mode. With the XChaCha20, it has a good defense against nonce collisions with it's 192-bit nonce size.

$\endgroup$

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.