JavacardOS will not accept order any more, please contact our partner Feitian online Store:
https://ftsafe.en.alibaba.com/index.html
https://ftsafe.en.alibaba.com/index.html
AES-CBC mode with padding
-
- Posts: 10
- Joined: Fri Jan 06, 2017 3:28 am
- Points :276
- Contact:
AES-CBC mode with padding
Hi I have a question about AES-CBC Algorithm
After decrypting the data with Cipher algorithm ALG_AES_CBC_ISO9797_M2, how can I get the real data without those paddings?
Since the padding data are some like "80 00 ...00 ", if the real data also contain the same content, how can I distinguish them?
Hope someone can help. Thanks a lot
After decrypting the data with Cipher algorithm ALG_AES_CBC_ISO9797_M2, how can I get the real data without those paddings?
Since the padding data are some like "80 00 ...00 ", if the real data also contain the same content, how can I distinguish them?
Hope someone can help. Thanks a lot
Re: AES-CBC mode with padding
What do you mean by getting those data without padding ?
Do you have a code fragment of your source code to show us so that we can guide you ?
I am not sure if you actually tried using the algorithm because if you do a encrypt or decrypt with the said mode of operation and padding, under the circumstance that the padding of the ciphertext is correct, the decrypted data returned automatically will be the actual data without any padding whatsoever. You need to supply the source code for us to comment further.
Do you have a code fragment of your source code to show us so that we can guide you ?
I am not sure if you actually tried using the algorithm because if you do a encrypt or decrypt with the said mode of operation and padding, under the circumstance that the padding of the ciphertext is correct, the decrypted data returned automatically will be the actual data without any padding whatsoever. You need to supply the source code for us to comment further.
-
- Posts: 34
- Joined: Mon Jun 29, 2015 9:03 pm
- Points :624
- Contact:
Re: AES-CBC mode with padding
The padding you're referring to is ISO 9797 Padding Method 2.
It is mandatory when encrypting data that the padding byte 0x80 is added, followed by as many 0x00's as required to pad to the next block multiple.
This is important, because it means that even if your data is already block-aligned, you _must_ add the 0x80 (which then means you have to add 15 0x00 bytes to complete the next full block). It may seem wasteful, but it's exactly for the scenario you are describing where the receiver does not necessarily know the length of the data being decrypted.
E.g.
0011223344556677 (8 bytes) would be padded to 00112233445566778000000000000000 (16 bytes)
112233445566778899AABBCCDDEEFF (16 bytes) would be padded to 112233445566778899AABBCCDDEEFF80000000000000000000000000000000 (32 bytes)
102030405060708000 (9 bytes) would be padded to 10203040506070800080000000000000 (16 bytes)
In the last example, even though the plaintext ends in 8000, you can be certain that the additional padding bytes were always added and therefore can be safely removed.
Here's a snippet of code for M2 padding:
It is mandatory when encrypting data that the padding byte 0x80 is added, followed by as many 0x00's as required to pad to the next block multiple.
This is important, because it means that even if your data is already block-aligned, you _must_ add the 0x80 (which then means you have to add 15 0x00 bytes to complete the next full block). It may seem wasteful, but it's exactly for the scenario you are describing where the receiver does not necessarily know the length of the data being decrypted.
E.g.
0011223344556677 (8 bytes) would be padded to 00112233445566778000000000000000 (16 bytes)
112233445566778899AABBCCDDEEFF (16 bytes) would be padded to 112233445566778899AABBCCDDEEFF80000000000000000000000000000000 (32 bytes)
102030405060708000 (9 bytes) would be padded to 10203040506070800080000000000000 (16 bytes)
In the last example, even though the plaintext ends in 8000, you can be certain that the additional padding bytes were always added and therefore can be safely removed.
Here's a snippet of code for M2 padding:
Code: Select all
private short addPaddingM2(byte[] buffer, short offset, short length) {
// Add the padding constant
buffer[length++] = (byte)0x80;
// Keep adding zeroes until you get to a block length (an empty block will return 1 block)
while (length < LENGTH_BLOCK_AES || (length % LENGTH_BLOCK_AES != 0)) {
buffer[length++] = 0x00;
}
return length; // Return the new length of the input data including padding
}
private short removePaddingM2(byte[] buffer, short offset, short length) {
// Remove the trailing zeroes
while ( (length != 0) && buffer[(short)(length - 1)] == (byte)0x00) length--;
// Test for the padding constant
if (buffer[(short)(length - 1)] != (byte)0x80 ) ISOException.throwIt(ISO7816.SW_DATA_INVALID);
length--; // Strip the 0x80 padding byte
return length; // Return the new length of the input data excluding padding
}
-
- Posts: 34
- Joined: Mon Jun 29, 2015 9:03 pm
- Points :624
- Contact:
Re: AES-CBC mode with padding
Just saw you were already using ALG_AES_CBC_ISO9797_M2 (I don't have access to this as I need to maintain Javacard 2.2.2 compatibility). The padding should be automatically added and removed and the return value of doFinal should give you the # of bytes of plaintext during decryption.
-
- Posts: 10
- Joined: Fri Jan 06, 2017 3:28 am
- Points :276
- Contact:
Re: AES-CBC mode with padding
tay00000 & kosullivan thanks very much for your answers and this really help a lot~
Who is online
Users browsing this forum: No registered users and 78 guests