Join Log in
Score:2
phantomcraft avatar Crypto

What would be the disadvantages of very large block sizes in block ciphers?

pf flag
phantomcraft

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?

88
0 + 0
Paul Uszak avatar
cn flag
Paul Uszak
Wouldn't fit onto an Arduino?
1
Reply
et flag
user93353
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
0
Reply
Paul Uszak avatar
cn flag
Paul Uszak
@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?
0
Reply
Paul Uszak avatar
cn flag
Paul Uszak
The dichotomy would grow in that modern crypto is designed for the lowest common denominator vis a vi hardware. One size must fit all/all eggs in one basket. No other field of human endeavour follows this principle, but it suits the NSA as the minimisation of the attack surface. So it wouldn't be allowed.
0
Reply
et flag
user93353
@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.
1
Reply
et flag
user93353
@PaulUszak - there are other reasons for not using stream ciphers in FDE - https://crypto.stackexchange.com/a/53544/3941
1
Reply
r3mainer avatar
us flag
r3mainer
Another problem would be latency. If you're encrypting a 64kbps MP3 stream with a block size of 65536 bits, then you'll have a 1 second coding delay at the transmitting end (possibly also at the receiving end, depending on the channel bandwidth).
0
Reply
Score:2
kelalaka avatar Crypto
in flag
kelalaka

  • 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.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.