AES-CBC Padding: Why always attach 16x 0x10 pad?
$begingroup$
Why do we have to always attach a 16x 0x10 pad even though the last block is already at block-length?
aes cbc padding
asked 2 days ago
NimeNime
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
Why do we have to always attach a 16x 0x10 pad even though the last block is already at block-length?
aes cbc padding
asked 2 days ago
NimeNime
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
Why do we have to always attach a 16x 0x10 pad even though the last block is already at block-length?
aes cbc padding
asked 2 days ago
NimeNime
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
Why do we have to always attach a 16x 0x10 pad even though the last block is already at block-length?
aes cbc padding
aes cbc padding
asked 2 days ago
NimeNime
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
NimeNime
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
NimeNime
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
NimeNime
383
asked 2 days ago
NimeNime
383
383
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Nime is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
You are talking about the PKCS#7 padding. There is a simple reason; assume that when the last block is full and you don't apply the padding before encryption and then send the message.
When decrypting, the receiver needs to see a padding pattern to remove the padding. What if the last byte is 01 of the message? is it padding or the message itself? Similarly with low probability same if the last bytes are 0202, and so on.
Instead of this, padding with 10 for an additional extra plaintext block solves the problem.
There are no reasons to perform this particular kind of padding if the plaintext size is known in advance. It may also not be required if the size of the plaintext can be determined by other means. For instance, ASCII encoded text will generally not contain a byte set to zero, so zero-byte padding may be used if the text is not a multiple of the block size. PKCS#7 padding can however always be removed deterministically, independently of the contents of the message.
Many modes, especially streaming modes such as the popular CTR (counter) mode and derivatives - such as the authenticated GCM mode - do not require padding at all; they operate on plaintext bytes rather than plaintext blocks.
edited 2 days ago
Maarten Bodewes♦
53.6k677193
answered 2 days ago
kelalakakelalaka
6,60022143
$endgroup$
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
2
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so10is only for message who are multiple of the blocksize, but other messages are also padded, with other values)
$endgroup$
– Faulst
2 days ago
1
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
3
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
|
show 2 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
});
}
});
Nime is a new contributor. Be nice, and check out our Code of Conduct.
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%2f66646%2faes-cbc-padding-why-always-attach-16x-0x10-pad%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$
You are talking about the PKCS#7 padding. There is a simple reason; assume that when the last block is full and you don't apply the padding before encryption and then send the message.
When decrypting, the receiver needs to see a padding pattern to remove the padding. What if the last byte is 01 of the message? is it padding or the message itself? Similarly with low probability same if the last bytes are 0202, and so on.
Instead of this, padding with 10 for an additional extra plaintext block solves the problem.
There are no reasons to perform this particular kind of padding if the plaintext size is known in advance. It may also not be required if the size of the plaintext can be determined by other means. For instance, ASCII encoded text will generally not contain a byte set to zero, so zero-byte padding may be used if the text is not a multiple of the block size. PKCS#7 padding can however always be removed deterministically, independently of the contents of the message.
Many modes, especially streaming modes such as the popular CTR (counter) mode and derivatives - such as the authenticated GCM mode - do not require padding at all; they operate on plaintext bytes rather than plaintext blocks.
edited 2 days ago
Maarten Bodewes♦
53.6k677193
answered 2 days ago
kelalakakelalaka
6,60022143
$endgroup$
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
2
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so10is only for message who are multiple of the blocksize, but other messages are also padded, with other values)
$endgroup$
– Faulst
2 days ago
1
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
3
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
|
show 2 more comments
$begingroup$
You are talking about the PKCS#7 padding. There is a simple reason; assume that when the last block is full and you don't apply the padding before encryption and then send the message.
When decrypting, the receiver needs to see a padding pattern to remove the padding. What if the last byte is 01 of the message? is it padding or the message itself? Similarly with low probability same if the last bytes are 0202, and so on.
Instead of this, padding with 10 for an additional extra plaintext block solves the problem.
There are no reasons to perform this particular kind of padding if the plaintext size is known in advance. It may also not be required if the size of the plaintext can be determined by other means. For instance, ASCII encoded text will generally not contain a byte set to zero, so zero-byte padding may be used if the text is not a multiple of the block size. PKCS#7 padding can however always be removed deterministically, independently of the contents of the message.
Many modes, especially streaming modes such as the popular CTR (counter) mode and derivatives - such as the authenticated GCM mode - do not require padding at all; they operate on plaintext bytes rather than plaintext blocks.
edited 2 days ago
Maarten Bodewes♦
53.6k677193
answered 2 days ago
kelalakakelalaka
6,60022143
$endgroup$
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
2
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so10is only for message who are multiple of the blocksize, but other messages are also padded, with other values)
$endgroup$
– Faulst
2 days ago
1
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
3
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
|
show 2 more comments
$begingroup$
You are talking about the PKCS#7 padding. There is a simple reason; assume that when the last block is full and you don't apply the padding before encryption and then send the message.
When decrypting, the receiver needs to see a padding pattern to remove the padding. What if the last byte is 01 of the message? is it padding or the message itself? Similarly with low probability same if the last bytes are 0202, and so on.
Instead of this, padding with 10 for an additional extra plaintext block solves the problem.
There are no reasons to perform this particular kind of padding if the plaintext size is known in advance. It may also not be required if the size of the plaintext can be determined by other means. For instance, ASCII encoded text will generally not contain a byte set to zero, so zero-byte padding may be used if the text is not a multiple of the block size. PKCS#7 padding can however always be removed deterministically, independently of the contents of the message.
Many modes, especially streaming modes such as the popular CTR (counter) mode and derivatives - such as the authenticated GCM mode - do not require padding at all; they operate on plaintext bytes rather than plaintext blocks.
edited 2 days ago
Maarten Bodewes♦
53.6k677193
answered 2 days ago
kelalakakelalaka
6,60022143
$endgroup$
You are talking about the PKCS#7 padding. There is a simple reason; assume that when the last block is full and you don't apply the padding before encryption and then send the message.
When decrypting, the receiver needs to see a padding pattern to remove the padding. What if the last byte is 01 of the message? is it padding or the message itself? Similarly with low probability same if the last bytes are 0202, and so on.
Instead of this, padding with 10 for an additional extra plaintext block solves the problem.
There are no reasons to perform this particular kind of padding if the plaintext size is known in advance. It may also not be required if the size of the plaintext can be determined by other means. For instance, ASCII encoded text will generally not contain a byte set to zero, so zero-byte padding may be used if the text is not a multiple of the block size. PKCS#7 padding can however always be removed deterministically, independently of the contents of the message.
Many modes, especially streaming modes such as the popular CTR (counter) mode and derivatives - such as the authenticated GCM mode - do not require padding at all; they operate on plaintext bytes rather than plaintext blocks.
edited 2 days ago
Maarten Bodewes♦
53.6k677193
answered 2 days ago
kelalakakelalaka
6,60022143
edited 2 days ago
Maarten Bodewes♦
53.6k677193
edited 2 days ago
Maarten Bodewes♦
53.6k677193
edited 2 days ago
Maarten Bodewes♦
53.6k677193
53.6k677193
answered 2 days ago
kelalakakelalaka
6,60022143
answered 2 days ago
kelalakakelalaka
6,60022143
answered 2 days ago
kelalakakelalaka
6,60022143
6,60022143
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
2
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so10is only for message who are multiple of the blocksize, but other messages are also padded, with other values)
$endgroup$
– Faulst
2 days ago
1
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
3
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
|
show 2 more comments
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
2
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so10is only for message who are multiple of the blocksize, but other messages are also padded, with other values)
$endgroup$
– Faulst
2 days ago
1
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
3
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
$begingroup$
Do we attach that to every message or only on those which are the multiple of the blocksize?
$endgroup$
– Nime
2 days ago
2
2
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so
10 is only for message who are multiple of the blocksize, but other messages are also padded, with other values)$endgroup$
– Faulst
2 days ago
$begingroup$
@Nime Take a look at the link in kelalaka's answer, the padding is explained. Short answer : The value of the bytes you add is the number of bytes you need to add in hexa (so
10 is only for message who are multiple of the blocksize, but other messages are also padded, with other values)$endgroup$
– Faulst
2 days ago
1
1
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@kelalaka I think there is a typo in your answer, it's not PKCS1.5 padding, but PKCS#5 (or PKCS#7, depending on who you asked)
$endgroup$
– Faulst
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
$begingroup$
@Faulst Thanks. corrected.
$endgroup$
– kelalaka
2 days ago
3
3
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
$begingroup$
And corrected again, PKCS#5 is for 8 byte block ciphers only, as explained here - changed it into PKCS#7 and put some reasons down below when PKCS#7 compatible padding is not required. @Faulst No, for AES it is always PKCS#7; if you'd ask this and they'd reply PKCS#5 compatible padding they'd be wrong.
$endgroup$
– Maarten Bodewes♦
2 days ago
|
show 2 more comments
Nime is a new contributor. Be nice, and check out our Code of Conduct.
Nime is a new contributor. Be nice, and check out our Code of Conduct.
Nime is a new contributor. Be nice, and check out our Code of Conduct.
Nime is a new contributor. Be nice, and check out our Code of Conduct.
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%2f66646%2faes-cbc-padding-why-always-attach-16x-0x10-pad%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
