Basic AES decryption problem

1

I'm working through the book Cryptography Engineering, and the current problem goes something like this:

Using an existing cryptography library, decrypt the following ciphertext (in hex form):

539b333b39706d149028cfe1d9d4a407

with the following 256-bit key (also in hex):

8000000000000000000000000000000000000000000000000000000000000001

using AES.

I'm a little stumped here. I'm using OpenSSL, but using the -aes256 parameter asks for an IV which clearly isn't given in this problem. Putting in all zeros for the IV yields bad decryption. Attempting to use some other AES encryption methods didn't get me much further. I may be in over my head here, but just trying to learn how this stuff works for fun. I'm a video game programmer so this is all new to me. Any assistance with this textbook problem would be greatly appreciated!

Note: I've done the exhaustive Stack Overflow and Google searches, but wasn't making any headway after about an hour.

Bennett Yeates

Posted 2015-08-15T19:07:37.713

Reputation: 113

Answers

3

Since no mode of operation is specified, and since the ciphertext length equals the size of one AES cipher block (128 bits = 32 hex digits = 16 bytes), it seems likely that you're expected to use the raw block cipher (a.k.a. "ECB mode").

You can, in fact, do this using openssl enc. The options you'll need are -aes-256-ecb, which will select the AES-256 cipher in ECB mode, and -nopad, which will turn off message padding.*

Of course, you'll also first need to convert the ciphertext from hex into raw bytes. (You can use the -K option to supply the key directly in hex.) The output plaintext will not be printable ASCII, but converting it back into hex should reveal a clear pattern.

*) In fact, your plaintext does happen to end in valid PKCS#7 padding, so openssl will happily decrypt it even without -nopad. However, I'm assuming that this is just a coincidence.

Ilmari Karonen

Posted 2015-08-15T19:07:37.713

Reputation: 1 509

Interesting! I did try the ecb method (although I forgot to mention it), but the output seemed misleading. It would seem I missed that step of converting it back to hex. What is the preferred way to do that? – Bennett Yeates – 2015-08-15T19:44:26.293

1

Any tool you used to convert the hex into raw bytes should presumably be able to do the reverse, too. Or you could run the output file through a hex dump tool like xxd.

– Ilmari Karonen – 2015-08-15T19:47:03.253

It would seem I missed that step as well. Thanks for the info! – Bennett Yeates – 2015-08-15T19:47:30.320

Wondering if I'm still doing this wrong. This is my command:

openssl.exe enc -d -aes-256-ecb -K 8000000000000000000000000000000000000000000000000000000000000001 -in ../Excersizes/AES-decrypt-256bitkey/output.bin -out ../Excersizes/AES-decrypt-256bitkey/plaintext.bin -nopad

Without the nopad I get "bad decrypt" – Bennett Yeates – 2015-08-15T20:13:46.683

1That command looks good to me. How many bytes long is your ciphertext file? And if you do a hex dump of it, does the content look like the hex string in the exercise? – Ilmari Karonen – 2015-08-15T20:17:01.990

Good question, looks like my text file containing the hex string needs to be converted to a hex dump? The xxd command I ran on the text file created the output.bin which is 0 bytes. – Bennett Yeates – 2015-08-15T20:18:46.313

Ok still got bad decrypt, but I have some readable hex in the plaintext. I got:

00000000: 372c e188 d0e4 c58d a352 1629 fee6 4f49 7,.......R.)..OI 00000010: 9cdb 878c 6d0e 30de 2402 4b6c 4711 384b ....m.0.$.KlG.8K

Did you see something similar? – Bennett Yeates – 2015-08-15T20:31:05.967

It looks like your ciphertext file is still wrong somehow. If you're on Linux (or have xxd for Windows), try the commands echo 539b333b39706d149028cfe1d9d4a407 > cipher.hex and xxd -r -p < cipher.hex > cipher.bin. The resulting cipher.bin file should be exactly 16 bytes long.

– Ilmari Karonen – 2015-08-15T21:52:47.880

That fixed it. Weird, I'm guessing using xxd to create the hex dump caused that problem? Seeing the plaintext as 80706050403020100807060504030201 – Bennett Yeates – 2015-08-15T21:56:24.787

I'm not sure how you "used xxd to create the hex dump" at all, seeing as how you had a hex string to start with. Did you perhaps accidentally hex-encode the ciphertext twice? Anyway, glad to see that you managed to solve it now. – Ilmari Karonen – 2015-08-15T22:03:31.093

Yup that's exactly what I did. Originally I was trying to convert it binary, but since the binary files were 0 bytes, I tried to create the hex dump with xxd using the ciphertext. – Bennett Yeates – 2015-08-15T22:18:30.563