Lightweight block ciphers that support decryption with minimal overhead?
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
asked Dec 30 '18 at 17:22
khan
1,248719
add a comment |
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
asked Dec 30 '18 at 17:22
khan
1,248719
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.
– b degnan
Dec 30 '18 at 18:27
@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.
– khan
Dec 30 '18 at 21:09
add a comment |
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
asked Dec 30 '18 at 17:22
khan
1,248719
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
encryption block-cipher modes-of-operation
asked Dec 30 '18 at 17:22
khan
1,248719
asked Dec 30 '18 at 17:22
khan
1,248719
edited Dec 30 '18 at 21:14
asked Dec 30 '18 at 17:22
khan
1,248719
asked Dec 30 '18 at 17:22
khan
1,248719
asked Dec 30 '18 at 17:22
khan
1,248719
1,248719
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.
– b degnan
Dec 30 '18 at 18:27
@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.
– khan
Dec 30 '18 at 21:09
add a comment |
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.
– b degnan
Dec 30 '18 at 18:27
@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.
– khan
Dec 30 '18 at 21:09
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.
– b degnan
Dec 30 '18 at 18:27
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.
– b degnan
Dec 30 '18 at 18:27
@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.
– khan
Dec 30 '18 at 21:09
@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.
– khan
Dec 30 '18 at 21:09
add a comment |
2 Answers
2
active
oldest
votes
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.
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
add a comment |
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.
answered Dec 30 '18 at 20:32
b degnan
1,7441626
there is not a difference in the "weight" of encryption and decryptionthis 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.
– Ella Rose♦
Dec 30 '18 at 20:34
@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.
– b degnan
Dec 30 '18 at 20:39
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
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.
– khan
Dec 30 '18 at 21:20
@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.
– b degnan
Dec 30 '18 at 21:44
|
show 4 more comments
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
add a comment |
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.
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
add a comment |
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.
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
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.
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
edited Dec 30 '18 at 21:46
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
answered Dec 30 '18 at 20:39
Ella Rose♦
15.3k44279
15.3k44279
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
add a comment |
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@no reason other than non-availability of counter mode? anyother possible scenario?
– khan
Dec 31 '18 at 4:55
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
@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.
– Ella Rose♦
Dec 31 '18 at 15:29
add a comment |
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.
answered Dec 30 '18 at 20:32
b degnan
1,7441626
there is not a difference in the "weight" of encryption and decryptionthis 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.
– Ella Rose♦
Dec 30 '18 at 20:34
@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.
– b degnan
Dec 30 '18 at 20:39
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
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.
– khan
Dec 30 '18 at 21:20
@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.
– b degnan
Dec 30 '18 at 21:44
|
show 4 more comments
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.
answered Dec 30 '18 at 20:32
b degnan
1,7441626
there is not a difference in the "weight" of encryption and decryptionthis 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.
– Ella Rose♦
Dec 30 '18 at 20:34
@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.
– b degnan
Dec 30 '18 at 20:39
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
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.
– khan
Dec 30 '18 at 21:20
@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.
– b degnan
Dec 30 '18 at 21:44
|
show 4 more comments
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.
answered Dec 30 '18 at 20:32
b degnan
1,7441626
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.
answered Dec 30 '18 at 20:32
b degnan
1,7441626
edited Dec 30 '18 at 20:40
answered Dec 30 '18 at 20:32
b degnan
1,7441626
answered Dec 30 '18 at 20:32
b degnan
1,7441626
answered Dec 30 '18 at 20:32
b degnan
1,7441626
1,7441626
there is not a difference in the "weight" of encryption and decryptionthis 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.
– Ella Rose♦
Dec 30 '18 at 20:34
@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.
– b degnan
Dec 30 '18 at 20:39
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
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.
– khan
Dec 30 '18 at 21:20
@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.
– b degnan
Dec 30 '18 at 21:44
|
show 4 more comments
there is not a difference in the "weight" of encryption and decryptionthis 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.
– Ella Rose♦
Dec 30 '18 at 20:34
@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.
– b degnan
Dec 30 '18 at 20:39
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
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.
– khan
Dec 30 '18 at 21:20
@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.
– b degnan
Dec 30 '18 at 21:44
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.– Ella Rose♦
Dec 30 '18 at 20:34
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.– Ella Rose♦
Dec 30 '18 at 20:34
@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.
– b degnan
Dec 30 '18 at 20:39
@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.
– b degnan
Dec 30 '18 at 20:39
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
@EllaRose I updated it to be more specific off your comments.
– b degnan
Dec 30 '18 at 20:40
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.
– khan
Dec 30 '18 at 21:20
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.
– khan
Dec 30 '18 at 21:20
@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.
– b degnan
Dec 30 '18 at 21:44
@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.
– b degnan
Dec 30 '18 at 21:44
|
show 4 more comments
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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.
– b degnan
Dec 30 '18 at 18:27
@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.
– khan
Dec 30 '18 at 21:09