0
$\begingroup$

I am trying to implement AES encryption on my own (128 bit key and ECB mode for now) and I can't seem to get expected results.

From what I understand about AES algorithm is that it divides message in 16 byte blocks and transforms those blocks, yielding encrypted 16 byte block.

However, when I tried using an online AES encyption tool encrypting a 16-byte message produced 32-byte output. How is that possible? What am I not understanding correctly?

Here is what my code is producing:

AES 128-bit ECB mode:
Both key and message = "YELLOW SUBMARINE" ([89, 69, 76, 76, 79, 87, 32, 83, 85, 66, 77, 65, 82, 73, 78, 69])
round 0: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
round 1: [0, 9, 65, 47, 79, 94, 97, 124, 26, 28, 44, 61, 72, 85, 98, 120]
round 2: [135, 75, 254, 54, 180, 212, 45, 177, 55, 2, 19, 171, 245, 13, 14, 143]
round 3: [50, 228, 122, 69, 241, 29, 196, 139, 131, 143, 104, 193, 67, 208, 166, 30]
round 4: [203, 114, 73, 191, 2, 96, 84, 247, 231, 25, 73, 117, 181, 42, 46, 190]
round 5: [229, 76, 18, 163, 173, 46, 175, 14, 198, 208, 175, 17, 206, 248, 241, 193]
round 6: [230, 181, 154, 180, 191, 239, 4, 97, 243, 30, 47, 98, 234, 110, 177, 95]
round 7: [235, 164, 135, 229, 96, 95, 167, 238, 235, 58, 88, 234, 62, 10, 215, 72]
round 8: [81, 88, 26, 75, 209, 221, 144, 221, 143, 1, 96, 226, 82, 144, 202, 235]
final round: [255, 193, 110, 59, 190, 199, 157, 156, 36, 243, 16, 60, 110, 132, 255, 227]

Here is the hex produced by online tool mentioned above: 0xD1AA4F6578926542FBB6DD876CD2050860FA36707E45F499DBA0F25B922301A5 or

[209, 170, 79, 101, 120, 146, 101, 66, 251, 182, 221, 135, 108, 210, 5, 8, 96, 250, 54, 112, 126, 69, 244, 153, 219, 160, 242, 91, 146, 35, 1, 165]

$\endgroup$
4
$\begingroup$

However, when I tried using an online AES encyption tool encrypting a 16-byte message produced 32-byte output. How is that possible? What am I not understanding correctly?

The tool in question seems poorly documented for implementation validation. It appears that it performs padding to deal with arbitrary length inputs. This padding is necessary if you want to encrypt arbitrary length messages in a reversible way, however, this implies that you need to add at least one message to the plaintext before encrypting it. This expansion yields the observation: A 16-byte message needs padding to ensure padding is there to be removed. However in a 16-byte block, there's no space for extra padding, so a second block is produced and appended only containing padding.

If you insist on using this tool, it should be possible to do so but just taking the first 16 bytes of the output as the plain input.

Alternatively, you can use tools that don't perform unspecified padding or use the test vectors specified in FIPS-197 (PDF).

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thank you so much! The file you have provided is perfect, wish I had found it earlier, would have made debugging so much easier. $\endgroup$ – Ach113 Oct 19 at 15:26
  • $\begingroup$ I have made clearer explanation of my problem here: crypto.stackexchange.com/questions/85660/… $\endgroup$ – Ach113 Oct 19 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.