What problems might you encounter if you use a block size much greater than AES?
What problems might you encounter if you use a block size much greater than AES (1000 bits, say)?
aes
asked Dec 2 '18 at 21:49
user63954
211
add a comment |
What problems might you encounter if you use a block size much greater than AES (1000 bits, say)?
aes
asked Dec 2 '18 at 21:49
user63954
211
1
Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big
– kelalaka
Dec 2 '18 at 21:57
2
Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me.
– lyrically wicked
Dec 4 '18 at 6:48
add a comment |
What problems might you encounter if you use a block size much greater than AES (1000 bits, say)?
aes
asked Dec 2 '18 at 21:49
user63954
211
What problems might you encounter if you use a block size much greater than AES (1000 bits, say)?
aes
aes
asked Dec 2 '18 at 21:49
user63954
211
asked Dec 2 '18 at 21:49
user63954
211
asked Dec 2 '18 at 21:49
user63954
211
asked Dec 2 '18 at 21:49
user63954
211
asked Dec 2 '18 at 21:49
user63954
211
211
1
Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big
– kelalaka
Dec 2 '18 at 21:57
2
Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me.
– lyrically wicked
Dec 4 '18 at 6:48
add a comment |
1
Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big
– kelalaka
Dec 2 '18 at 21:57
2
Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me.
– lyrically wicked
Dec 4 '18 at 6:48
1
1
Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big
– kelalaka
Dec 2 '18 at 21:57
Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big
– kelalaka
Dec 2 '18 at 21:57
2
2
Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me.
– lyrically wicked
Dec 4 '18 at 6:48
Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me.
– lyrically wicked
Dec 4 '18 at 6:48
add a comment |
2 Answers
2
active
oldest
votes
It may be very tricky to have a good distribution / diffusion of the input bits for each round. That would mean that you would either require a very intricate design for each round, or a lot of rounds to make up for it.
Furthermore it will also mean that you need to perform an operation of at least 1000 bits to perform any kind of calculation. This is not a desirable property in most circumstances. For some modes of operation such as CBC, it will mean that the minimum message size would be 1000 bits - and the IV would take up another 1000 bits. For counter (CTR) mode your message will not grow as only part of the output can be used. However, that still means doing 1000 bit calculations for possibly much smaller messages.
Most modes of operation function quite well for block sizes of 128 bits, although 256 bits would be beneficial for modes such as CTR (because the IV is split between a nonce and the counter).
Although a large block size is desirable for use in the design of hash functions, the avalanche effect does require a good diffusion of bits. Threefish - the block cipher used for Skein, one of the SHA-3 finalists - however does support a block size of 1024 bits, so ~1000 bits is certainly not unheard of (quite often the internal hash state is at least double the intermediate / output size). Skein 512 however requires 80 (!) rounds of Threefish1024 so it certainly wasn't the fastest algorithm out there.
A relatively fast large block cipher may also be beneficial for some format preserving encryption, by the way. In principle a single block encrypt of a unique value is secure, so having a large block size may be helpful avoid repetition of blocks. You could build a cipher with a larger block size from a block cipher with a small block size, but those kind of constructs are generally not all that efficient.
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
add a comment |
This problem has been studied and comes under wider block-cipher encryptions, examples are Mercy block cipher , Bear and Lion , and Simpira.
My answer ties with Simpira block cipher case.
Simpira has been recently developed to work on 64 bit processors (v2 is also available) which uses 128 bit x b , where b is a positive integer.
Simpira is a cryptographic permutation that combines AES and Feistel structure.
In Simpira cipher , the number of rounds required to achieve full diffusion increases along the b value , (12,15,21 rounds for b=1,2,3).This means , to achieve full diffusion of wider size more rounds are required therefore performance will downgrade.
for further information: Simpira
answered Dec 4 '18 at 9:51
hardyrama
7181425
add a comment |
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%2f64502%2fwhat-problems-might-you-encounter-if-you-use-a-block-size-much-greater-than-aes%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
It may be very tricky to have a good distribution / diffusion of the input bits for each round. That would mean that you would either require a very intricate design for each round, or a lot of rounds to make up for it.
Furthermore it will also mean that you need to perform an operation of at least 1000 bits to perform any kind of calculation. This is not a desirable property in most circumstances. For some modes of operation such as CBC, it will mean that the minimum message size would be 1000 bits - and the IV would take up another 1000 bits. For counter (CTR) mode your message will not grow as only part of the output can be used. However, that still means doing 1000 bit calculations for possibly much smaller messages.
Most modes of operation function quite well for block sizes of 128 bits, although 256 bits would be beneficial for modes such as CTR (because the IV is split between a nonce and the counter).
Although a large block size is desirable for use in the design of hash functions, the avalanche effect does require a good diffusion of bits. Threefish - the block cipher used for Skein, one of the SHA-3 finalists - however does support a block size of 1024 bits, so ~1000 bits is certainly not unheard of (quite often the internal hash state is at least double the intermediate / output size). Skein 512 however requires 80 (!) rounds of Threefish1024 so it certainly wasn't the fastest algorithm out there.
A relatively fast large block cipher may also be beneficial for some format preserving encryption, by the way. In principle a single block encrypt of a unique value is secure, so having a large block size may be helpful avoid repetition of blocks. You could build a cipher with a larger block size from a block cipher with a small block size, but those kind of constructs are generally not all that efficient.
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
add a comment |
It may be very tricky to have a good distribution / diffusion of the input bits for each round. That would mean that you would either require a very intricate design for each round, or a lot of rounds to make up for it.
Furthermore it will also mean that you need to perform an operation of at least 1000 bits to perform any kind of calculation. This is not a desirable property in most circumstances. For some modes of operation such as CBC, it will mean that the minimum message size would be 1000 bits - and the IV would take up another 1000 bits. For counter (CTR) mode your message will not grow as only part of the output can be used. However, that still means doing 1000 bit calculations for possibly much smaller messages.
Most modes of operation function quite well for block sizes of 128 bits, although 256 bits would be beneficial for modes such as CTR (because the IV is split between a nonce and the counter).
Although a large block size is desirable for use in the design of hash functions, the avalanche effect does require a good diffusion of bits. Threefish - the block cipher used for Skein, one of the SHA-3 finalists - however does support a block size of 1024 bits, so ~1000 bits is certainly not unheard of (quite often the internal hash state is at least double the intermediate / output size). Skein 512 however requires 80 (!) rounds of Threefish1024 so it certainly wasn't the fastest algorithm out there.
A relatively fast large block cipher may also be beneficial for some format preserving encryption, by the way. In principle a single block encrypt of a unique value is secure, so having a large block size may be helpful avoid repetition of blocks. You could build a cipher with a larger block size from a block cipher with a small block size, but those kind of constructs are generally not all that efficient.
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
add a comment |
It may be very tricky to have a good distribution / diffusion of the input bits for each round. That would mean that you would either require a very intricate design for each round, or a lot of rounds to make up for it.
Furthermore it will also mean that you need to perform an operation of at least 1000 bits to perform any kind of calculation. This is not a desirable property in most circumstances. For some modes of operation such as CBC, it will mean that the minimum message size would be 1000 bits - and the IV would take up another 1000 bits. For counter (CTR) mode your message will not grow as only part of the output can be used. However, that still means doing 1000 bit calculations for possibly much smaller messages.
Most modes of operation function quite well for block sizes of 128 bits, although 256 bits would be beneficial for modes such as CTR (because the IV is split between a nonce and the counter).
Although a large block size is desirable for use in the design of hash functions, the avalanche effect does require a good diffusion of bits. Threefish - the block cipher used for Skein, one of the SHA-3 finalists - however does support a block size of 1024 bits, so ~1000 bits is certainly not unheard of (quite often the internal hash state is at least double the intermediate / output size). Skein 512 however requires 80 (!) rounds of Threefish1024 so it certainly wasn't the fastest algorithm out there.
A relatively fast large block cipher may also be beneficial for some format preserving encryption, by the way. In principle a single block encrypt of a unique value is secure, so having a large block size may be helpful avoid repetition of blocks. You could build a cipher with a larger block size from a block cipher with a small block size, but those kind of constructs are generally not all that efficient.
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
It may be very tricky to have a good distribution / diffusion of the input bits for each round. That would mean that you would either require a very intricate design for each round, or a lot of rounds to make up for it.
Furthermore it will also mean that you need to perform an operation of at least 1000 bits to perform any kind of calculation. This is not a desirable property in most circumstances. For some modes of operation such as CBC, it will mean that the minimum message size would be 1000 bits - and the IV would take up another 1000 bits. For counter (CTR) mode your message will not grow as only part of the output can be used. However, that still means doing 1000 bit calculations for possibly much smaller messages.
Most modes of operation function quite well for block sizes of 128 bits, although 256 bits would be beneficial for modes such as CTR (because the IV is split between a nonce and the counter).
Although a large block size is desirable for use in the design of hash functions, the avalanche effect does require a good diffusion of bits. Threefish - the block cipher used for Skein, one of the SHA-3 finalists - however does support a block size of 1024 bits, so ~1000 bits is certainly not unheard of (quite often the internal hash state is at least double the intermediate / output size). Skein 512 however requires 80 (!) rounds of Threefish1024 so it certainly wasn't the fastest algorithm out there.
A relatively fast large block cipher may also be beneficial for some format preserving encryption, by the way. In principle a single block encrypt of a unique value is secure, so having a large block size may be helpful avoid repetition of blocks. You could build a cipher with a larger block size from a block cipher with a small block size, but those kind of constructs are generally not all that efficient.
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
edited Dec 2 '18 at 22:30
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
answered Dec 2 '18 at 22:23
Maarten Bodewes♦
52.9k677191
52.9k677191
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
add a comment |
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
Happy to upvote any other answers, especially those who actually designed a block cipher... Please do not accept yet.
– Maarten Bodewes♦
Dec 3 '18 at 9:07
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
It is very interesting how Keccak algorithm manages to deal with 1600-bit blocks using only 24 (or even twelve!) rounds...
– lyrically wicked
Dec 4 '18 at 6:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
Yeah, but if you would ever try to implement it Keccak's F is not exactly a peach to implement. Especially if you're a nut like me and try to do it "from spec".
– Maarten Bodewes♦
Dec 4 '18 at 14:49
add a comment |
This problem has been studied and comes under wider block-cipher encryptions, examples are Mercy block cipher , Bear and Lion , and Simpira.
My answer ties with Simpira block cipher case.
Simpira has been recently developed to work on 64 bit processors (v2 is also available) which uses 128 bit x b , where b is a positive integer.
Simpira is a cryptographic permutation that combines AES and Feistel structure.
In Simpira cipher , the number of rounds required to achieve full diffusion increases along the b value , (12,15,21 rounds for b=1,2,3).This means , to achieve full diffusion of wider size more rounds are required therefore performance will downgrade.
for further information: Simpira
answered Dec 4 '18 at 9:51
hardyrama
7181425
add a comment |
This problem has been studied and comes under wider block-cipher encryptions, examples are Mercy block cipher , Bear and Lion , and Simpira.
My answer ties with Simpira block cipher case.
Simpira has been recently developed to work on 64 bit processors (v2 is also available) which uses 128 bit x b , where b is a positive integer.
Simpira is a cryptographic permutation that combines AES and Feistel structure.
In Simpira cipher , the number of rounds required to achieve full diffusion increases along the b value , (12,15,21 rounds for b=1,2,3).This means , to achieve full diffusion of wider size more rounds are required therefore performance will downgrade.
for further information: Simpira
answered Dec 4 '18 at 9:51
hardyrama
7181425
add a comment |
This problem has been studied and comes under wider block-cipher encryptions, examples are Mercy block cipher , Bear and Lion , and Simpira.
My answer ties with Simpira block cipher case.
Simpira has been recently developed to work on 64 bit processors (v2 is also available) which uses 128 bit x b , where b is a positive integer.
Simpira is a cryptographic permutation that combines AES and Feistel structure.
In Simpira cipher , the number of rounds required to achieve full diffusion increases along the b value , (12,15,21 rounds for b=1,2,3).This means , to achieve full diffusion of wider size more rounds are required therefore performance will downgrade.
for further information: Simpira
answered Dec 4 '18 at 9:51
hardyrama
7181425
This problem has been studied and comes under wider block-cipher encryptions, examples are Mercy block cipher , Bear and Lion , and Simpira.
My answer ties with Simpira block cipher case.
Simpira has been recently developed to work on 64 bit processors (v2 is also available) which uses 128 bit x b , where b is a positive integer.
Simpira is a cryptographic permutation that combines AES and Feistel structure.
In Simpira cipher , the number of rounds required to achieve full diffusion increases along the b value , (12,15,21 rounds for b=1,2,3).This means , to achieve full diffusion of wider size more rounds are required therefore performance will downgrade.
for further information: Simpira
answered Dec 4 '18 at 9:51
hardyrama
7181425
edited Dec 4 '18 at 11:04
answered Dec 4 '18 at 9:51
hardyrama
7181425
answered Dec 4 '18 at 9:51
hardyrama
7181425
answered Dec 4 '18 at 9:51
hardyrama
7181425
7181425
add a comment |
add a comment |
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%2f64502%2fwhat-problems-might-you-encounter-if-you-use-a-block-size-much-greater-than-aes%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
1
Are there any such Cryptographic algorithm? If you have a secure one 1) Small messages will be very big. 2) key size will be big. 3) big,big big
– kelalaka
Dec 2 '18 at 21:57
2
Theoretically, MD6 compression function (described in Chapter 2.5 and Chapter 9 of the document “The MD6 hash function: A proposal to NIST for SHA-3”) is defined for any block size (assuming that the block size is a multiple of the word size). Since 1000 is divisible by 8, it would be possible to define this function for 1000-bit blocks. There are two serious problems though: 1) The number of rounds required to ensure the security is very big; 2) The algorithm relies on heuristic ways to choose optimal parameters for each block/word size. The second problem is what really annoys me.
– lyrically wicked
Dec 4 '18 at 6:48