Cfrtjryk

Lightweight block ciphers are mostly expressed for encryption routine and efforts are made to keep it as light as possible mostly in terms of gates count and power usage although some try to keep latency and critical path in consideration. The designers assume that such lightweight block ciphers will be used in a mode of operation which does not need the decryption routine like Counter mode. However, a few innovative designs also support the decryption routine with minimal overhead in terms of gate count like PRINCE and Piccolo block cipher.

Piccolo needs just 60 extra gates to support decryption on top of encryption circuitry.

• Why is there a need for a lightweight block cipher to support decryption routine?




• What all other lightweight block ciphers support decryption with minimal overhead in terms of gate count?

I know feistel structures do support decryption by using round keys in reverse order, but we are talking here about lightweight block ciphers. These are implemented in resource constrained devices and really small implementations of these lightweight block ciphers often cant afford to store expanded keys so even feistel structures do need extra gates to manage these issues for supporting decyption.

I do know modes other than Counter like CBC needs implementation of decryption methods, but what practical scenarios force this to happen. Cant the implementers just use counter mode.

Why is there a need for lightweight block cipher to support decryption routine?

You might want to use a mode that is not based on CTR mode, which will require the availability of the decryption procedure.

What all other lightweight block ciphers support decryption with minimal overhead?

Any designs that are Feistel networks and/or use components that are involutions will offer minimal overhead for the decryption procedure.

The following designs mention using components that are involutions, according to wikipedia:

• Anubis


• KHAZAD


• Cellular Message Encryption Algorithm


• MULTI2


• NOEKEON

This list is probably not exhaustive.

From the hardware perspective, there is not a difference in the "weight" of encryption and decryption because the key schedules are invertible in a Feistel Network. For AES, you need to double the hardware; however, the electrical cost is the same for both encryption and decryption. You do have different initial conditions, and sometimes you need to reconfigure a LFSR; however, you usually just save these in hardware somewhere. As an example, using the simontool program that I used to verify my ICs with encryption for SIMON128/128, I can show the steps of the cryptotext to be

simontool -e -b 128 -k 128 -s 0000000000000000000000000000000 -t 00000000000000000000000000000000 -y

and then decryption using

simontool -d -b 128 -k 128 -s bd33c82094c520f5bff3c91ea5140348 -t d4c7356f31e6f70287b1a055ac1cff31 -y

You can easily see the invertible nature of the cipher and there is no difference in power or speed, but just initial conditions of the LFSR, starting from the expanded key and starting with the encrypted data.