Using Padding in Encryption
The most common query we get about cryptography concerns padding with a block cipher.
If you have to encrypt some data to send to another user and everything else works OK except the last few bytes, your problem is probably one of padding. Read on.
This article describes the mechanics of padding with examples using common block encryption algorithms like AES, Triple DES and Blowfish. It considers where you should use padding and where you don't need to.
- What is padding?
- Security considerations
- Example of ECB mode
- Example using Blowfish in CBC mode
- What about ciphers like AES that use larger block sizes?
- Example using AES
- Cipher-Feedback (CFB) and Output-Feedback (OFB) Modes
- When don't I need to use padding?
- Example using Triple DES without padding
- Using random padding
- So when do I use padding and when don't I?
- Other Information
Block cipher algorithms like AES and Triple DES in Electronic Code Book (ECB) and Cipher Block Chaining (CBC) mode require their input to be an exact multiple of the block size. If the plaintext to be encrypted is not an exact multiple, you need to pad before encrypting by adding a padding string. When decrypting, the receiving party needs to know how to remove the padding in an unambiguous manner.
- There are major security issues in using ECB mode (duplicate plaintext blocks give the same ciphertext block) and its use is generally discouraged.
- CBC mode can leak information if handled incorrectly.
- Care must be taken to use a unique initialization vector (IV) or counter with all methods that require one for a given key.
- There are limits on the amount of plaintext that can be safely encrypted with a given (key, IV) pair.
The plain text is the ASCII encoding of
Now is the time for".
That is, the 19-byte sequence
4E 6F 77 20 69 73 20 74 68 65 20 74 69 6D 65 20 66 6F 72.
We are encrypting using DES in ECB mode with the cryptographic key
To encrypt, we break up the plaintext into blocks of 8 bytes
(Note we are using 8 in this example because the block
size for DES is 64 bits or 8 bytes; if this were AES we'd be using 16 bytes).
Note: Using DES with a single 64-bit key is definitely no longer recommended, but we use it here for simplicity to demonstrate the principle of padding for an 8-byte block. It is easy to extend this to a more-secure 192-bit Triple DES key or 256-bit Blowfish key. Similarly we use ECB mode to avoid the complications of initialization vectors.
N o w _ i s _ t h e _ t i m e _ f o r 4E 6F 77 20 69 73 20 74 68 65 20 74 69 6D 65 20 66 6F 72breaks up into two blocks of 8 bytes plus an odd three bytes at the end
+-----------------------+-----------------------+-----------------------+ |N o w _ i s _ t |h e t i m e _ |f o r ? ? ? ? ? | +-----------------------+-----------------------+-----------------------+ |4E 6F 77 20 69 73 20 74|68 65 20 74 69 6D 65 20|66 6F 72 ?? ?? ?? ?? ??| +-----------------------+-----------------------+-----------------------+In ECB mode, each 8-byte block is encrypted independently.
DES INPUT BLOCK = N o w _ i s _ t (IN HEX) 4E 6F 77 20 69 73 20 74 DES OUTPUT BLOCK = 3F A4 0E 8A 98 4D 43 15Second block:
DES INPUT BLOCK = h e _ t i m e _ (IN HEX) 68 65 20 74 69 6D 65 20 DES OUTPUT BLOCK = 6A 27 17 87 AB 88 83 F9So far, so good. But what do we do with the odd characters at the end of our plaintext?
DES INPUT BLOCK = f o r ?? ?? ?? ?? ?? (IN HEX) 66 6F 72 ?? ?? ?? ?? ??
We need to pad the block with padding bytes to make it up to the required length. There are at least five common conventions:-
- Pad with bytes all of the same value as the number of padding bytes
- Pad with 0x80 followed by zero bytes
- Pad with zeroes except make the last byte equal to the number of padding bytes
- Pad with zero (null) characters
- Pad with space characters
Method one is the most popular and is usually referred to as "PKCS5 padding". It is generally recommended in the absence of any other considerations.
Hint: If you are short of time and don't want to read all of this document, use PKCS5 padding.
Method 1 - Pad with bytes all of the same value as the number of padding bytes (PKCS5 padding)This is the method described in section 6.1.1 of [PKCS5], and is the same as the padding method in section 6.3 of [CMS], section 10.3 of [PKCS7], and para 1.1 of [RFC1423].
Pad the input with a padding string of between 1 and 8 bytes to make the total length an exact multiple of 8 bytes. The value of each byte of the padding string is set to the number of bytes added - i.e. 8 bytes of value 0x08, 7 bytes of value 0x07, ..., 2 bytes of 0x02, or one byte of value 0x01.Our fourth block is padded with 5 bytes of value 0x05:
DES INPUT BLOCK = f o r _ _ _ _ _ (IN HEX) 66 6F 72 05 05 05 05 05 KEY = 01 23 45 67 89 AB CD EF DES OUTPUT BLOCK = FD 29 85 C9 E8 DF 41 40
After decrypting, read the last character decrypted and strip off that many bytes.
This method can be used with any plaintext, ASCII or binary. Don't forget to check first that the number of characters to be stripped is between one and eight. This also gives you an extra check that the decryption has been carried out correctly (well, if its value is not between 1 and 8 you know for sure that is hasn't, but if it is, it doesn't necessarily mean it has). As an additional check, check all of the padding bytes.
Method 2 - Pad with 0x80 followed by zero bytes (OneAndZeroes Padding)
Add a single padding byte of value 0x80 and then pad the balance with enough bytes of value zero to make the total length an exact multiple of 8 bytes. If the single 0x80 byte makes the total length an exact multiple then do not add any zero bytes. This is known as "OneAndZeroes padding" (and general usage seems to retain the arguably incorrect spelling of "zeroes"!).Our fourth block is padded with 0x80 followed by 4 bytes of value 0x00:
DES INPUT BLOCK = f o r _ _ _ _ _ (IN HEX) 66 6F 72 80 00 00 00 00 KEY = 01 23 45 67 89 AB CD EF DES OUTPUT BLOCK = BE 62 5D 9F F3 C6 C8 40
After decrypting, strip off all trailing zero bytes and the 0x80 byte.
This method can be used with any plaintext, ASCII or binary. Again, you have a check for incorrect decryption if you don't find the expected padding bytes at the end. Cryptographers who work with smart cards seem to prefer this method, see [RANK]. It is recommended in NIST 800-38a [BCMO]. In their latest book [FERG], Niels Ferguson and Bruce Schneier recommend either this method or method 1.
Method 3 - Pad with zeroes except make the last byte equal to the number of padding bytesOur fourth block is padded with 4 null characters (0x00) followed by a byte with value 0x05:
DES INPUT BLOCK = f o r _ _ _ _ _ (IN HEX) 66 6f 72 00 00 00 00 05 KEY = 01 23 45 67 89 AB CD EF DES OUTPUT BLOCK = 91 19 2C 64 B5 5C 5D B8
This is a variant of method 1 described in [SCHN]. The convention with this method is usually always to add a padding string, even if the original plaintext was already an exact multiple of 8 bytes. The final byte could therefore have a value between 0x01 and 0x08.
After decrypting, read the last character decrypted and strip off that many bytes (checking first that its value is between one and eight).
This method can be used with any plaintext, ASCII or binary.
Method 4 - Pad with zero (null) charactersOur fourth block is padded with 5 null characters (0x00):
DES INPUT BLOCK = f o r _ _ _ _ _ (IN HEX) 66 6f 72 00 00 00 00 00 KEY = 01 23 45 67 89 AB CD EF DES OUTPUT BLOCK = 9E 14 FB 96 C5 FE EB 75
After decrypting, trim all null characters found at the end until you find a non-null character. You cannot use this method when the plaintext could contain a null value. This is not a problem if you are dealing with ASCII text, but would be if encrypting binary data like an EXE file.
Method 5 - Pad with spacesOur fourth block is padded with 5 space characters (0x20):
DES INPUT BLOCK = f o r _ _ _ _ _ (IN HEX) 66 6f 72 20 20 20 20 20 KEY = 01 23 45 67 89 AB CD EF DES OUTPUT BLOCK = E3 FF EC E5 21 1F 35 25You will find this method used in EDI applications where the plaintext is simple ASCII text and does not have trailing spaces at the end. The convention is usually that if the original plaintext is already an exact multiple of eight, then no padding is added, otherwise the last block is padded with space characters up to the next multiple of eight. See, for example, [NZEDI]
After decrypting, just trim any trailing space characters, if any
The resulting ciphertext from these five methods will be as follows:
|-- block 1 ---| |-- block 2 ---| |-- block 3 ---| 1. 3FA40E8A984D4315 6A271787AB8883F9 FD2985C9E8DF4140 2. 3FA40E8A984D4315 6A271787AB8883F9 BE625D9FF3C6C840 3. 3FA40E8A984D4315 6A271787AB8883F9 91192C64B55C5DB8 4. 3FA40E8A984D4315 6A271787AB8883F9 9E14FB96C5FEEB75 5. 3FA40E8A984D4315 6A271787AB8883F9 E3FFECE5211F3525Note how different the last blocks are.
This example is from Eric Young's set of test vectors for Blowfish. Note that the plaintext data includes a trailing null character (0x00) after the final space character (0x20).
key = 0123456789ABCDEFF0E1D2C3B4A59687 iv = FEDCBA9876543210 data = "7654321 Now is the time for " (includes trailing '\0') data = 37363534333231204E6F77206973207468652074696D6520666F722000 Method 1 PKCS5 method IN: 37363534333231204E6F77206973207468652074696D6520666F722000030303 OUT: 6B77B4D63006DEE605B156E27403979358DEB9E7154616D9749DECBEC05D264B ^^^^^^^^^^^^^^^^ Method 2 Pad with 0x80 + zeros IN: 37363534333231204E6F77206973207468652074696D6520666F722000800000 OUT: 6B77B4D63006DEE605B156E27403979358DEB9E7154616D9BB3F8B9254003C40 ^^^^^^^^^^^^^^^^ Method 3 Pad with nulls + # bytes IN: 37363534333231204E6F77206973207468652074696D6520666F722000000003 OUT: 6B77B4D63006DEE605B156E27403979358DEB9E7154616D9A078DBB46155E4AC ^^^^^^^^^^^^^^^^ Method 4 Pad with nulls (this is the method used in the test vectors) IN: 37363534333231204E6F77206973207468652074696D6520666F722000000000 OUT: 6B77B4D63006DEE605B156E27403979358DEB9E7154616D959F1652BD5FF92CC ^^^^^^^^^^^^^^^^ Method 5 Pad with spaces IN: 37363534333231204E6F77206973207468652074696D6520666F722000202020 OUT: 6B77B4D63006DEE605B156E27403979358DEB9E7154616D9332223899980E694 ^^^^^^^^^^^^^^^^
Note that the last 8 bytes of ciphertext are all completely different. For this example, because the plaintext contains trailing space characters and nulls, the padding in methods 4 and 5 cannot be removed unabiguously.
More modern block ciphers like the Advanced Encryption Algorithm (AES) have larger block sizes than DES and Blowfish. All the arguments above still apply, except you should replace the number 8 with the appropriate block size in bytes. For example, if using AES with a 128-bit block, pad to the next multiple of 16. Note, too, that it is the block size that matters, not the size of the key.
Example using AESThis example uses AES-128 to encrypt a short message "Hello" using the 128-bit key
0xA456B7A422C5145ABCF2B3CB206579A8. The block size of 128 bits is equal to 128/8 = 16 bytes, so we need to pad our 5-byte plaintext with an 11-byte padding string. The ASCII characters "Hello" are 48656C6C6F in hexadecimal and 11 decimal = 0x0B.
Method 1 PKCS5 method AES INPUT BLOCK = 48656C6C6F0B0B0B0B0B0B0B0B0B0B0B AES OUTPUT BLOCK = 42FF63CC06D53DA93F24389723E1611A Method 2 Pad with 0x80 + zeros AES INPUT BLOCK = 48656C6C6F8000000000000000000000 AES OUTPUT BLOCK = 97AFA1455DA9E2E1B821275997CF4DC5 Method 3 Pad with nulls + # bytes AES INPUT BLOCK = 48656C6C6F000000000000000000000B AES OUTPUT BLOCK = 6024D07C11283639425E3A33D99F32BA Method 4 Pad with nulls AES INPUT BLOCK = 48656C6C6F0000000000000000000000 AES OUTPUT BLOCK = 3FC6C30A64CD6E2970803871C7068998 Method 5 Pad with spaces AES INPUT BLOCK = 48656C6C6F2020202020202020202020 AES OUTPUT BLOCK = 7FB72E7BE929223D001E3129DFFA20A0Note that, in this instance where the message is shorter than the block size, the resulting output is completely different in each case.
If you encrypt using Cipher-Feedback (CFB) or Output-Feedback (OFB) or counter (CTR) modes then the ciphertext will be the same size as the plaintext and so padding is not required. Be careful, though, when using these modes, because the initialisation vectors (IV) must be unique.
Similarly, encrypting using a stream cipher like RC4 or PC1 does not require padding.
You need to communicate a packet of information that is always the same format:-
|Customer reference number:||5 digits||12345|
|Credit card number:||15 digits||376066666655555|
|Expiry date:||4 digits||1205|
This is always 24 bytes long, so if we are encrypting with DES or Triple DES or Blowfish, our data is always a fixed multiple of the block size. There is no need to add any padding to this before encrypting, provided that you and the recipient agree not to.
Example using Triple DES with key
ASCII PLAINTEXT: 123453760666666555551205 3DES INPUT BLOCKS: 12345376 06666665 55551205 INPUT IN HEX: 3132333435333736 3036363636363635 3535353531323035 3DES OUTPUT: 7ADE45981580DB32 421E3D90B5B47D5B 1175FA3DD8B932D7
If you are transmitting messages that are shorter than the block length and encrypting using ECB mode, your ciphertext will be identical for identical messages. One solution is to use a variant of method 3 but use random padding bytes instead of nulls.
Alternatively, if the size of your encrypted message might give some information away, add a random number of random padding bytes to the message.
0xfedcba9876543210using the PKCS5 method of padding we will always end up with the same result:
ACSII PLAINTEXT: buy (IN HEX): 627579 INPUT BLOCK: 6275790505050505 KEY: FEDCBA9876543210 OUTPUT BLOCK: C2666697D381CA11
We could use a variant of our method 3 above using random padding bytes instead of nulls. The final byte tells us how many bytes to strip after deciphering. The following two examples use four random padding bytes plus 0x05 and produce completely different results.
ACSII PLAINTEXT: buy (IN HEX): 627579 INPUT BLOCK: 62757958B3989B05 KEY: FEDCBA9876543210 OUTPUT BLOCK: 061FF118B96F4EE8
ACSII PLAINTEXT: buy (IN HEX): 627579 INPUT BLOCK: 62757934297CC805 KEY: FEDCBA9876543210 OUTPUT BLOCK: AAE42B7527A9078A
A receiving party with the correct key could derive the original plaintext from any such message. An attacker is now faced with solving many more alternatives.
Note that this will only work for a short message. You can achieve the same security by using CBC mode with a unique Initialisation Vector (IV), but you then have the overhead of having to transmit the IV as well as the ciphertext.
As a very contrived example, let's say we might be sending two alternative messages that read:
Offer $90000.00 OR Offer $1000000.00Let's say we use the PKCS5 method of padding when we encrypt these two messages using Blowfish in CBC mode with 128-bit key
ASCII PT: Offer $90000.00 (IN HEX): 4F66666572202439303030302E3030 INPUT: 4F66666572202439303030302E303001 OUTPUT: 33BEF550BADE4798DDA5C960E2C70EB9
ASCII PT: Offer $1000000.00 (IN HEX): 4F666665722024313030303030302E3030 INPUT: 4F666665722024313030303030302E303007070707070707 OUTPUT: A4B8D1BF3020DB24CDD459BAB6A7BA7B02AC39EE7C1BF090
An eavesdropper who knows that the message may contain either $90,000 or $1,000,000 could work out the answer just from the length of the ciphertext.
One solution is to add a random number of random bytes as padding, and to indicate the number of random bytes added by the last byte in padded input block.
ASCII PT: Offer $90000.00 (IN HEX): 4F66666572202439303030302E3030 INPUT: 4F66666572202439303030302E303012441C0D5E2C60147DF54910B6A6445311 OUTPUT: 33BEF550BADE4798B164164E571A5266B0D488FAD934D6386494FAF528C8ED82
ASCII PT: Offer $1000000.00 (IN HEX): 4F666665722024313030303030302E3030 INPUT: 4F666665722024313030303030302E3030CEF8302A84BA07 OUTPUT: A4B8D1BF3020DB24CDD459BAB6A7BA7BC01DF3FCC3B7DC1B
This particular convention of using only the last byte limits you to 255 random padding bytes. It may be more practical to encode your plaintext with a header that indicates the number of valid bytes that follow plus a much larger random number of random padding bytes and then encrypt that.
- To encrypt data of variable length, use padding with CBC mode.
To avoid any ambiguity, make it standard practice always to add
- If your plaintext data is always a fixed length equal to a multiple of the block size (8 or 16), you can avoid using padding.
- If you use CFB or OFB modes of encryption, or use a stream cipher like RC4, Salsa20 or ChaCha20, then you don't use padding.
- [BCMO] NIST Special Publication 800-38A Recommendations for Block Cipher Modes of Operation, Methods and Techniques, Morris Dworkin, December 2001.
- [CMS] RFC 5652 Cryptographic Message Syntax (CMS), R. Housley, September 2009 (obsoletes RFC 3852, RFC 3369 and RFC 2630).
- [FERG] Niels Ferguson and Bruce Schneier, Practical Cryptography, John Wiley, 2003 (Latest edition).
- [FIPS46] Federal Information Processing Standard (FIPS) 46-3, Data Encryption Standard (DES), U.S. Department Of Commerce/National Institute of Standards and Technology, 25 October 1999.
- [FIPS74] Federal Information Processing Standard 74 (FIPS PUB 74), Guidelines for Implementing and Using the NBS Data Encryption Standard, U.S. Department Of Commerce/National Institute of Standards and Technology, 1 April 1981.
- [FIPS81] Federal Information Processing Standard (FIPS 81), DES Modes of Operation, U.S. Department Of Commerce/National Institute of Standards and Technology, 2 December 1980.
- [FIPS197] Federal Information Processing Standards Publication FIPS PUB 197 Advanced Encryption Standard (AES), U.S. Department Of Commerce/National Institute of Standards and Technology, 26 November 2001.
- [MENE] Menezes, van Oorschot and Vanstone, Handbook of Applied Cryptography, CRC Press LLC, 1997.
- [NZEDI] New Zealand Customs Service, EDI Message Implementation Guidelines for Customs Declarations, 15 November 1999.
- [PKCS5] PKCS #5, Password-Based Encryption Standard, RSA Laboratories, Version 2.0, March 1999.
- [PKCS7] PKCS #7, Cryptographic Message Syntax Standard, RSA Laboratories, Version 1.5, November 1993.
- [RANK] Rankl, W and W. Effing, Smart Card Handbook, John Wiley, 1997.
- [RFC1423] RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, D. Balenson, February 1993 (Status: HISTORIC).
- [SCHN] Bruce Schneier, Applied Cryptography - Protocols, Algorithms and Source Code in C, second edition, John Wiley, 1996.
- [STAL] William Stallings, Cryptography and Network Security: Principles and Practice, 7th edition, Pearson, 2016.
- [TMOVS] NIST Special Publication 800-20 Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures, April 2000.
- An introduction to using keys in cryptography.
- Ciphertext is not text! - Storing and representing ciphertext.
- Cross-platform encryption.
- Encryption with international character sets.
- Encrypting variable-length strings with a password.
To comment on this page or ask a question, please send us a message.
This page last updated 30 March 2016