0

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?

mikeazo
  • 38,563
  • 8
  • 112
  • 180
Rina
  • 1
  • 2
  • 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 09:13
  • 1
    I have no idea what you are trying to ask – Richie Frame Apr 17 '15 at 09: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 05:44
  • Your question is incomprehensible. You should give an example with some sample plaintexts and the corresponding ciphertexts, and explain exactly how they're computed (like you did in your comment, but it's unreadable due to the lack of formatting: edit your question). Also tell us how you're generating the IV. – Gilles 'SO- stop being evil' Apr 20 '15 at 12:47
  • Can you post the pattern that you are seeing? Is it "=="? It is hard to tell by your comment (please just edit the question), but it looks like you are doing a base64 encoding of the cipher text, which explains why you would see a repeated pattern at the end. – mikeazo Apr 20 '15 at 14:28
  • 1
    See: http://crypto.stackexchange.com/questions/20941/why-shouldnt-i-use-ecb-encryption – Ilmari Karonen Apr 22 '15 at 17:15

1 Answers1

1

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
Community
  • 1
PHolder
  • 13
  • 2