# Multiple AES/ECB encryptions of different data with same key all end with same pattern

We have used "AES/ECB/PKCS5Padding" with a 256 bit key. We encrypt different streams of data (blockwise) with the same key. Each encrypted stream ends with same pattern. What is the reason for this?

• Ok so key is the "secret key" that stays the same, output is what you call "encryption key" because that's what you want to generate (by the way there are dedicated algorithms for that, like Key Derivation Functions), but... what's the message, the plaintext you provided AES-CBC with ? – Cédric Van Rompay Apr 17 '15 at 9:13
• I have no idea what you are trying to ask – Richie Frame Apr 17 '15 at 9:56
• Maybe you are doing a base64 encode after encryption? – mikeazo Apr 19 '15 at 19:31
• -Used AES-256 as key generator -AES/ECB/PKCS5Padding as Cipher transformation -Decoded shared key (common plain text key) is decoded with "Base64" ,its provided with "AES" byte[] raw1 = Base64.decodeBase64(sharedSecretKey.getBytes()); SecretKeySpec skey = new SecretKeySpec(raw1, "AES"); cipher.init(Cipher.ENCRYPT_MODE, skey); -generated encrypted key is encoded with "Base64" – Rina Apr 20 '15 at 5:44
• – Ilmari Karonen Apr 22 '15 at 17:15

ECB is possibly the wrong choice for your application, you more likely want CBC or some other mode. See https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29 in particular the picture of the Tux penguin for an example of why ECB does not work with duplicated data.

So now the question is why you would have duplicated data at the end of your output. This is because of the way the padding is working. You said you were using PKCS5Padding and it, by design, always adds a full extra AES block at the end of the of input. (You can see https://en.wikipedia.org/wiki/Padding_%28cryptography%29 but that doesn't appear to cover PKCS #5, but maybe this is useful What is the difference between PKCS#5 padding and PKCS#7 padding )

It appears you are working in Java, and so I coded up a quick little bit of Java test code, to demonstrate what is happening:

encryptData(secret, cipher, "A123456789012345678901234567890", "First Example");
encryptData(secret, cipher, "B123456789012345678901234567890", "Second Example");
encryptData(secret, cipher, "C123456789012345678901234567890", "Third Example");


Which produces this output:

First Example(32 bytes)
0000: CE F9 BF 06 1B 70 5F E5 C2 E7 2D 49 E3 BE A1 EC
0010: D6 E7 45 DE 6B 05 F5 FB 95 87 FC DD EE 57 40 FC
Second Example(32 bytes)
0000: 5F 5F 8E EE D8 FC F9 55 AD EA 5F 76 D8 5D FD C1
0010: D6 E7 45 DE 6B 05 F5 FB 95 87 FC DD EE 57 40 FC
Third Example(32 bytes)
0000: 26 27 23 96 82 39 3D D0 9C DF 51 83 0F A7 20 F6
0010: D6 E7 45 DE 6B 05 F5 FB 95 87 FC DD EE 57 40 FC


As you can see, all three different inputs produce the same output for the last block of:

0010: D6 E7 45 DE 6B 05 F5 FB 95 87 FC DD EE 57 40 FC


When I re-run the code, making the changes necessary for CBC mode (with a preset IV instead of a random one), the output changes to this:

First Example(32 bytes)
0000: 77 F7 51 60 59 F4 54 3C 31 9B F4 C6 72 1C C8 63
0010: C0 D9 32 35 49 93 A7 BA B1 6D 65 EC 66 7D 3C 98
Second Example(32 bytes)
0000: FE B8 B2 1F B9 56 73 AF 61 B3 50 9E DC 69 F3 C6
0010: 1F 5C F0 40 FD 1D 30 D0 CA 5C 0F 06 1B 2E 89 67
Third Example(32 bytes)
0000: 6E 85 6A 02 CA 0B E4 33 E3 29 47 D9 B5 C0 86 01
0010: AE A0 AA 22 1F 12 E5 6A 10 31 9D 0F 99 8F 9A 6E


Here you can plainly see the blocks are all very different.

I have posted the code examples for each case into a pastebin. They rely on some library code to dump the bytes to hex, but I don't think you need that code for your own work, so I didn't worry about including it, and it would be easy to replace.

 ECB: https://pastebin.com/FSbJ5AfE
CBC: https://pastebin.com/PP8c44J4