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?
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