Can we implement AES with 16 bit block size ?if so what are its advantages and disadvantages?Is there any rule AES has to be implemented with 128,192,256 ?Can we use AES for odd number of bits(17,33,37..) ?

  • $\begingroup$ You could use AES in FFX mode. $\endgroup$ – CodesInChaos Sep 10 '15 at 7:29

I am assuming that you wish to consider this for standard encryption tasks, and I am going to ignore the specific reference to AES and talk about general block ciphers (pseudorandom permutations).

The answer is that small block sizes are very problematic. In particular, they break when used for encryption of any reasonable amount of information. I will consider two concrete examples. In CBC mode, security breaks down after $2^{n/2}$ blocks, when $n$ is the block length. This means that you could not encrypt more than $2^8=256$ blocks, which is just 512 bytes. This is due to birthday collisions. However, it's actually worse than this. The probability of having a collision at less than 256 blocks is not so small, and at such small numbers it is very problematic. If you use CTR mode, then once again you have a problem since the nonce/IV has to be unique. Even if you are using this from fresh each time with a new key, and so just use a counter beginning at 0, you still have a problem that you can't encrypt more than $2^{16}$ blocks, which is just 128KB.

Regarding constructing such a small block cipher, this can be done using the techniques from format-preserving encryption. You use a Feistel, but you need many rounds with such a small block (also making it very inefficient). Specifically, you need 24 rounds of Feistel (this is the current recommendation but there is also a concerning lack of clarity regarding the exact security in this case).

| improve this answer | |
  • $\begingroup$ could you please provide a reference for the 24 round unbalanced festeil you're writing about ? Thx $\endgroup$ – Alexandre Yamajako Sep 10 '15 at 8:47
  • $\begingroup$ I was referring to a balanced cipher. But, just look at the format-preserving encryption literature as mentioned by @CodesInChaos. $\endgroup$ – Yehuda Lindell Sep 10 '15 at 8:54
  • $\begingroup$ I like the answer. Mathematically it's possible to adjust the Rijndael's parameters to fit more than the 3 standard sizes (the original proposal was with 5 sizes). For odd number of bits, you need an odd wordsize (originally 8 bits), but this will make you to build specific SBoxes for it. The box is a composition of two operations for whom you have to have some background. Also mixColumns will require an study to adjust parameters. $\endgroup$ – srgblnch Sep 10 '15 at 11:05
  • $\begingroup$ @srgblnch I strongly warn against making any changes to Rijndael (or even to AES). Once you look at other parameters or you make changes, all of confidence built by years of cryptanalysis goes out the window. This has been shown many times. You change the SBox and/or you change the mixColumns and you have no confidence whatsoever in the security. $\endgroup$ – Yehuda Lindell Sep 10 '15 at 12:48
  • $\begingroup$ Yes, you are right: don't change an algorithm to use it in production. Furthermore, don't implement your crypto because there are many audited libraries. What I've said is mathematically it is possible as well as it can be studied cryptoanalytically the repercussions of any difference. $\endgroup$ – srgblnch Sep 10 '15 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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