Lightweight block ciphers that support decryption with minimal overhead?












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.










share|improve this question











$endgroup$












  • $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 '18 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$
    – khan
    Dec 30 '18 at 21:09
















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.










share|improve this question











$endgroup$












  • $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 '18 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$
    – khan
    Dec 30 '18 at 21:09














3












3








3


1



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










share|improve this question











$endgroup$




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.







encryption block-cipher modes-of-operation






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 30 '18 at 21:14







khan

















asked Dec 30 '18 at 17:22









khankhan

1,253719




1,253719












  • $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 '18 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$
    – khan
    Dec 30 '18 at 21:09


















  • $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 '18 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$
    – khan
    Dec 30 '18 at 21:09
















$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 '18 at 18:27




$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 '18 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$
– khan
Dec 30 '18 at 21:09




$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$
– khan
Dec 30 '18 at 21:09










2 Answers
2






active

oldest

votes


















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:




  • Anubis

  • KHAZAD

  • Cellular Message Encryption Algorithm

  • MULTI2

  • NOEKEON


This list is probably not exhaustive.






share|improve this answer











$endgroup$













  • $begingroup$
    @no reason other than non-availability of counter mode? anyother possible scenario?
    $endgroup$
    – khan
    Dec 31 '18 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 '18 at 15:29



















0












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






share|improve this answer











$endgroup$









  • 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 '18 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 '18 at 20:39










  • $begingroup$
    @EllaRose I updated it to be more specific off your comments.
    $endgroup$
    – b degnan
    Dec 30 '18 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$
    – khan
    Dec 30 '18 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 '18 at 21:44











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66179%2flightweight-block-ciphers-that-support-decryption-with-minimal-overhead%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









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:




  • Anubis

  • KHAZAD

  • Cellular Message Encryption Algorithm

  • MULTI2

  • NOEKEON


This list is probably not exhaustive.






share|improve this answer











$endgroup$













  • $begingroup$
    @no reason other than non-availability of counter mode? anyother possible scenario?
    $endgroup$
    – khan
    Dec 31 '18 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 '18 at 15:29
















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:




  • Anubis

  • KHAZAD

  • Cellular Message Encryption Algorithm

  • MULTI2

  • NOEKEON


This list is probably not exhaustive.






share|improve this answer











$endgroup$













  • $begingroup$
    @no reason other than non-availability of counter mode? anyother possible scenario?
    $endgroup$
    – khan
    Dec 31 '18 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 '18 at 15:29














2












2








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:




  • Anubis

  • KHAZAD

  • Cellular Message Encryption Algorithm

  • MULTI2

  • NOEKEON


This list is probably not exhaustive.






share|improve this answer











$endgroup$




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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 30 '18 at 21:46

























answered Dec 30 '18 at 20:39









Ella RoseElla Rose

15.9k44281




15.9k44281












  • $begingroup$
    @no reason other than non-availability of counter mode? anyother possible scenario?
    $endgroup$
    – khan
    Dec 31 '18 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 '18 at 15:29


















  • $begingroup$
    @no reason other than non-availability of counter mode? anyother possible scenario?
    $endgroup$
    – khan
    Dec 31 '18 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 '18 at 15:29
















$begingroup$
@no reason other than non-availability of counter mode? anyother possible scenario?
$endgroup$
– khan
Dec 31 '18 at 4:55




$begingroup$
@no reason other than non-availability of counter mode? anyother possible scenario?
$endgroup$
– khan
Dec 31 '18 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 '18 at 15:29




$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 '18 at 15:29











0












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






share|improve this answer











$endgroup$









  • 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 '18 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 '18 at 20:39










  • $begingroup$
    @EllaRose I updated it to be more specific off your comments.
    $endgroup$
    – b degnan
    Dec 30 '18 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$
    – khan
    Dec 30 '18 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 '18 at 21:44
















0












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






share|improve this answer











$endgroup$









  • 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 '18 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 '18 at 20:39










  • $begingroup$
    @EllaRose I updated it to be more specific off your comments.
    $endgroup$
    – b degnan
    Dec 30 '18 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$
    – khan
    Dec 30 '18 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 '18 at 21:44














0












0








0





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






share|improve this answer











$endgroup$



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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 30 '18 at 20:40

























answered Dec 30 '18 at 20:32









b degnanb degnan

1,8601627




1,8601627








  • 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 '18 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 '18 at 20:39










  • $begingroup$
    @EllaRose I updated it to be more specific off your comments.
    $endgroup$
    – b degnan
    Dec 30 '18 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$
    – khan
    Dec 30 '18 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 '18 at 21:44














  • 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 '18 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 '18 at 20:39










  • $begingroup$
    @EllaRose I updated it to be more specific off your comments.
    $endgroup$
    – b degnan
    Dec 30 '18 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$
    – khan
    Dec 30 '18 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 '18 at 21:44








1




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 '18 at 20:34




$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 '18 at 20:34




1




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 '18 at 20:39




$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 '18 at 20:39












$begingroup$
@EllaRose I updated it to be more specific off your comments.
$endgroup$
– b degnan
Dec 30 '18 at 20:40




$begingroup$
@EllaRose I updated it to be more specific off your comments.
$endgroup$
– b degnan
Dec 30 '18 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$
– khan
Dec 30 '18 at 21:20




$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$
– khan
Dec 30 '18 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 '18 at 21:44




$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 '18 at 21:44


















draft saved

draft discarded




















































Thanks for contributing an answer to Cryptography Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66179%2flightweight-block-ciphers-that-support-decryption-with-minimal-overhead%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Сан-Квентин

Алькесар

Josef Freinademetz