Would this mode of operation be safer?
$begingroup$
Here the key stream is used as keys for the second level of block cipher encryption.
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
- stream cipher attack, because it isn't just simply XOR-d
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
- Am I correct in the above?
- Are there any more advantages to this architecture?
- Any further disadvantages?
Explanation: I modified the standard CTR mode by replacing the XOR with a full block cipher, which has the Keystream(i) values as keys for encrypting or decrypting the successive blocks of plaintext/ciphertext.
encryption modes-of-operation
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
$endgroup$
add a comment |
$begingroup$
Here the key stream is used as keys for the second level of block cipher encryption.
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
- stream cipher attack, because it isn't just simply XOR-d
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
- Am I correct in the above?
- Are there any more advantages to this architecture?
- Any further disadvantages?
Explanation: I modified the standard CTR mode by replacing the XOR with a full block cipher, which has the Keystream(i) values as keys for encrypting or decrypting the successive blocks of plaintext/ciphertext.
encryption modes-of-operation
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
$endgroup$
$begingroup$
Malleability isn't something someone using authenticated encryption should be concerned about. Someone who isn't using authenticated encryption is someone you should be concerned about. (Use GCM (GMAC), HMAC, or Poly1305.)
$endgroup$
– Future Security
Dec 16 '18 at 17:18
$begingroup$
Not yet sure if it is safe or not, but it looks quite slow. You have twice the number of block operations as most other modes. And moreover you are using different keys all the time which can increase the cost even further.
$endgroup$
– kasperd
Dec 16 '18 at 22:49
add a comment |
$begingroup$
Here the key stream is used as keys for the second level of block cipher encryption.
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
- stream cipher attack, because it isn't just simply XOR-d
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
- Am I correct in the above?
- Are there any more advantages to this architecture?
- Any further disadvantages?
Explanation: I modified the standard CTR mode by replacing the XOR with a full block cipher, which has the Keystream(i) values as keys for encrypting or decrypting the successive blocks of plaintext/ciphertext.
encryption modes-of-operation
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
$endgroup$
Here the key stream is used as keys for the second level of block cipher encryption.
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
- stream cipher attack, because it isn't just simply XOR-d
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
- Am I correct in the above?
- Are there any more advantages to this architecture?
- Any further disadvantages?
Explanation: I modified the standard CTR mode by replacing the XOR with a full block cipher, which has the Keystream(i) values as keys for encrypting or decrypting the successive blocks of plaintext/ciphertext.
encryption modes-of-operation
encryption modes-of-operation
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
edited Dec 16 '18 at 15:02
Maarten Bodewes♦
54.7k679194
54.7k679194
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
asked Dec 16 '18 at 15:00
Balazs FBalazs F
61
61
$begingroup$
Malleability isn't something someone using authenticated encryption should be concerned about. Someone who isn't using authenticated encryption is someone you should be concerned about. (Use GCM (GMAC), HMAC, or Poly1305.)
$endgroup$
– Future Security
Dec 16 '18 at 17:18
$begingroup$
Not yet sure if it is safe or not, but it looks quite slow. You have twice the number of block operations as most other modes. And moreover you are using different keys all the time which can increase the cost even further.
$endgroup$
– kasperd
Dec 16 '18 at 22:49
add a comment |
$begingroup$
Malleability isn't something someone using authenticated encryption should be concerned about. Someone who isn't using authenticated encryption is someone you should be concerned about. (Use GCM (GMAC), HMAC, or Poly1305.)
$endgroup$
– Future Security
Dec 16 '18 at 17:18
$begingroup$
Not yet sure if it is safe or not, but it looks quite slow. You have twice the number of block operations as most other modes. And moreover you are using different keys all the time which can increase the cost even further.
$endgroup$
– kasperd
Dec 16 '18 at 22:49
$begingroup$
Malleability isn't something someone using authenticated encryption should be concerned about. Someone who isn't using authenticated encryption is someone you should be concerned about. (Use GCM (GMAC), HMAC, or Poly1305.)
$endgroup$
– Future Security
Dec 16 '18 at 17:18
$begingroup$
Malleability isn't something someone using authenticated encryption should be concerned about. Someone who isn't using authenticated encryption is someone you should be concerned about. (Use GCM (GMAC), HMAC, or Poly1305.)
$endgroup$
– Future Security
Dec 16 '18 at 17:18
$begingroup$
Not yet sure if it is safe or not, but it looks quite slow. You have twice the number of block operations as most other modes. And moreover you are using different keys all the time which can increase the cost even further.
$endgroup$
– kasperd
Dec 16 '18 at 22:49
$begingroup$
Not yet sure if it is safe or not, but it looks quite slow. You have twice the number of block operations as most other modes. And moreover you are using different keys all the time which can increase the cost even further.
$endgroup$
– kasperd
Dec 16 '18 at 22:49
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would likely be vulnerable to padding oracle attacks; they are not avoided by the mode itself.
- stream cipher attack, because it isn't just simply XOR-d
Although you would not be vulnerable to a many-time-pad if the nonce is repeated, you would of course still leak information on each block of ciphertext that is identical, at the same location. That's slightly worse than e.g. CBC mode, where a change in plaintext would change all next ciphertext blocks if the IV is ever repeated.
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
It doesn't, it just changes on block of plaintext at the same block offset. You would still be malleable if you would change the entire plaintext by the way (imagine encrypting a single bit, 0 for false or 1 for true!). So you need to expand your ciphertext - usually with an authentication tag - to avoid malleability. This is not a description of an authenticated cipher.
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
Correct. And because you are using a lot of keys, you may run into trouble with regards on how the key space needs to be treated for a specific cipher. You would definitely worry about keys repeating simply due to the birthday paradox.
Are there any more advantages to this architecture?
Not that I see, it adds an additional round that introduces problems, while solving none; counter mode is already considered secure. With double the additional rounds + a key schedule per block it is rather expensive for what it tries to achieve.
Any further disadvantages?
I don't think we need more disadvantages, but I'll show some for learning purposes.
One disadvantage is that your key and block size need to be identical. So using e.g. AES-256 is not possible (even if it would be advisable because you may not want to use a cipher that is vulnerable against related key attacks, even if those are mostly theoretical in nature).
You would lose the pre-computation benefits of counter mode, where you can cache the key stream. You can still do that of course, but the last block encrypt / decrypt can only be performed once the plaintext is available.
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
$endgroup$
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%2f65909%2fwould-this-mode-of-operation-be-safer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would likely be vulnerable to padding oracle attacks; they are not avoided by the mode itself.
- stream cipher attack, because it isn't just simply XOR-d
Although you would not be vulnerable to a many-time-pad if the nonce is repeated, you would of course still leak information on each block of ciphertext that is identical, at the same location. That's slightly worse than e.g. CBC mode, where a change in plaintext would change all next ciphertext blocks if the IV is ever repeated.
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
It doesn't, it just changes on block of plaintext at the same block offset. You would still be malleable if you would change the entire plaintext by the way (imagine encrypting a single bit, 0 for false or 1 for true!). So you need to expand your ciphertext - usually with an authentication tag - to avoid malleability. This is not a description of an authenticated cipher.
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
Correct. And because you are using a lot of keys, you may run into trouble with regards on how the key space needs to be treated for a specific cipher. You would definitely worry about keys repeating simply due to the birthday paradox.
Are there any more advantages to this architecture?
Not that I see, it adds an additional round that introduces problems, while solving none; counter mode is already considered secure. With double the additional rounds + a key schedule per block it is rather expensive for what it tries to achieve.
Any further disadvantages?
I don't think we need more disadvantages, but I'll show some for learning purposes.
One disadvantage is that your key and block size need to be identical. So using e.g. AES-256 is not possible (even if it would be advisable because you may not want to use a cipher that is vulnerable against related key attacks, even if those are mostly theoretical in nature).
You would lose the pre-computation benefits of counter mode, where you can cache the key stream. You can still do that of course, but the last block encrypt / decrypt can only be performed once the plaintext is available.
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
$endgroup$
add a comment |
$begingroup$
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would likely be vulnerable to padding oracle attacks; they are not avoided by the mode itself.
- stream cipher attack, because it isn't just simply XOR-d
Although you would not be vulnerable to a many-time-pad if the nonce is repeated, you would of course still leak information on each block of ciphertext that is identical, at the same location. That's slightly worse than e.g. CBC mode, where a change in plaintext would change all next ciphertext blocks if the IV is ever repeated.
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
It doesn't, it just changes on block of plaintext at the same block offset. You would still be malleable if you would change the entire plaintext by the way (imagine encrypting a single bit, 0 for false or 1 for true!). So you need to expand your ciphertext - usually with an authentication tag - to avoid malleability. This is not a description of an authenticated cipher.
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
Correct. And because you are using a lot of keys, you may run into trouble with regards on how the key space needs to be treated for a specific cipher. You would definitely worry about keys repeating simply due to the birthday paradox.
Are there any more advantages to this architecture?
Not that I see, it adds an additional round that introduces problems, while solving none; counter mode is already considered secure. With double the additional rounds + a key schedule per block it is rather expensive for what it tries to achieve.
Any further disadvantages?
I don't think we need more disadvantages, but I'll show some for learning purposes.
One disadvantage is that your key and block size need to be identical. So using e.g. AES-256 is not possible (even if it would be advisable because you may not want to use a cipher that is vulnerable against related key attacks, even if those are mostly theoretical in nature).
You would lose the pre-computation benefits of counter mode, where you can cache the key stream. You can still do that of course, but the last block encrypt / decrypt can only be performed once the plaintext is available.
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
$endgroup$
add a comment |
$begingroup$
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would likely be vulnerable to padding oracle attacks; they are not avoided by the mode itself.
- stream cipher attack, because it isn't just simply XOR-d
Although you would not be vulnerable to a many-time-pad if the nonce is repeated, you would of course still leak information on each block of ciphertext that is identical, at the same location. That's slightly worse than e.g. CBC mode, where a change in plaintext would change all next ciphertext blocks if the IV is ever repeated.
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
It doesn't, it just changes on block of plaintext at the same block offset. You would still be malleable if you would change the entire plaintext by the way (imagine encrypting a single bit, 0 for false or 1 for true!). So you need to expand your ciphertext - usually with an authentication tag - to avoid malleability. This is not a description of an authenticated cipher.
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
Correct. And because you are using a lot of keys, you may run into trouble with regards on how the key space needs to be treated for a specific cipher. You would definitely worry about keys repeating simply due to the birthday paradox.
Are there any more advantages to this architecture?
Not that I see, it adds an additional round that introduces problems, while solving none; counter mode is already considered secure. With double the additional rounds + a key schedule per block it is rather expensive for what it tries to achieve.
Any further disadvantages?
I don't think we need more disadvantages, but I'll show some for learning purposes.
One disadvantage is that your key and block size need to be identical. So using e.g. AES-256 is not possible (even if it would be advisable because you may not want to use a cipher that is vulnerable against related key attacks, even if those are mostly theoretical in nature).
You would lose the pre-computation benefits of counter mode, where you can cache the key stream. You can still do that of course, but the last block encrypt / decrypt can only be performed once the plaintext is available.
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
$endgroup$
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would likely be vulnerable to padding oracle attacks; they are not avoided by the mode itself.
- stream cipher attack, because it isn't just simply XOR-d
Although you would not be vulnerable to a many-time-pad if the nonce is repeated, you would of course still leak information on each block of ciphertext that is identical, at the same location. That's slightly worse than e.g. CBC mode, where a change in plaintext would change all next ciphertext blocks if the IV is ever repeated.
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
It doesn't, it just changes on block of plaintext at the same block offset. You would still be malleable if you would change the entire plaintext by the way (imagine encrypting a single bit, 0 for false or 1 for true!). So you need to expand your ciphertext - usually with an authentication tag - to avoid malleability. This is not a description of an authenticated cipher.
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
Correct. And because you are using a lot of keys, you may run into trouble with regards on how the key space needs to be treated for a specific cipher. You would definitely worry about keys repeating simply due to the birthday paradox.
Are there any more advantages to this architecture?
Not that I see, it adds an additional round that introduces problems, while solving none; counter mode is already considered secure. With double the additional rounds + a key schedule per block it is rather expensive for what it tries to achieve.
Any further disadvantages?
I don't think we need more disadvantages, but I'll show some for learning purposes.
One disadvantage is that your key and block size need to be identical. So using e.g. AES-256 is not possible (even if it would be advisable because you may not want to use a cipher that is vulnerable against related key attacks, even if those are mostly theoretical in nature).
You would lose the pre-computation benefits of counter mode, where you can cache the key stream. You can still do that of course, but the last block encrypt / decrypt can only be performed once the plaintext is available.
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
edited Dec 16 '18 at 15:50
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
answered Dec 16 '18 at 15:16
Maarten Bodewes♦Maarten Bodewes
54.7k679194
54.7k679194
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.
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%2f65909%2fwould-this-mode-of-operation-be-safer%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
$begingroup$
Malleability isn't something someone using authenticated encryption should be concerned about. Someone who isn't using authenticated encryption is someone you should be concerned about. (Use GCM (GMAC), HMAC, or Poly1305.)
$endgroup$
– Future Security
Dec 16 '18 at 17:18
$begingroup$
Not yet sure if it is safe or not, but it looks quite slow. You have twice the number of block operations as most other modes. And moreover you are using different keys all the time which can increase the cost even further.
$endgroup$
– kasperd
Dec 16 '18 at 22:49