3
$\begingroup$

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.

Improve this question
$\endgroup$
2
  • $\begingroup$ In what way do you find there being a greater cost than encryption? Generally, we just store the key twice. The original key and then the expansion key so you can just run it backwards. $\endgroup$
    – b degnan
    Dec 30, 2018 at 18:27
  • $\begingroup$ @bdegnan so implementing a decryption circut for the cipher does need extra gate. And in case of SPN, mostly decryption methods have higher implementaton cost, for example AES MDS matrix for encryption and decryption have different implementation cost. $\endgroup$
    – crypt
    Dec 30, 2018 at 21:09

2 Answers 2

Reset to default
2
$\begingroup$

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:

This list is probably not exhaustive.

Improve this answer
$\endgroup$
2
  • $\begingroup$ @no reason other than non-availability of counter mode? anyother possible scenario? $\endgroup$
    – crypt
    Dec 31, 2018 at 4:55
  • $\begingroup$ @khan Not that I can think of, but that doesn't mean that there are no more reasons. Try investigating the motivation section of the relevant designs. $\endgroup$
    – Ella Rose
    Dec 31, 2018 at 15:29
1
$\begingroup$

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

enter image description here

and then decryption using 

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

enter image description here

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.

Improve this answer
$\endgroup$
9
  • 1
    $\begingroup$ there is not a difference in the "weight" of encryption and decryption this is only true for certain ciphers, e.g. Feistel networks. A counter example is AES; Decryption in AES is not just reversing the round keys, you have to implement the inverse s-box and inverse mix columns routines. $\endgroup$
    – Ella Rose
    Dec 30, 2018 at 20:34
  • 1
    $\begingroup$ @EllaRose That is correct for AES where you need 2x the hardware; however, the power costs is the same and the transistor count is the same so I believe my statement holds. $\endgroup$
    – b degnan
    Dec 30, 2018 at 20:39
  • $\begingroup$ @EllaRose I updated it to be more specific off your comments. $\endgroup$
    – b degnan
    Dec 30, 2018 at 20:40
  • $\begingroup$ in hardware, decryption often gets more costly because effort was put in place to keep encryption lightest. example is MDS matrix of AES for encryption and decryption. $\endgroup$
    – crypt
    Dec 30, 2018 at 21:20
  • $\begingroup$ @khan From a hardware perspective, that statement is categorically false as symmetric encryption is invertible. It's not ever "harder", as it's just hard. If you were talking about MPEG, we put a lot of effort to make decompression easy as all of the specifications are based on a minimally viable VLSI implementation. The same is true for asymmetric encryption. If what you are saying is true, I've never seen it in silicon and gratefully appreciate a reference. $\endgroup$
    – b degnan
    Dec 30, 2018 at 21:44

Your Answer

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

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