2

I am testing OpenSSL by executing the Known Answer tests provided here.

When using AES-128-CBC with the following parameters:

KEY = 00000000000000000000000000000000
IV = 00000000000000000000000000000000
Input = f34481ec3cc627bacd5dc3fb08f273e6

the output should be the following: 0336763e966d92595a567cc9ce537f5e

I executed the following command in my terminal:

openssl aes-128-cbc -e -in in.txt -out out.txt -K  00000000000000000000000000000000 -iv 00000000000000000000000000000000 -p -nosalt

where the in.txt file contains my input, I get an output file with gibberish. I am assuming that it is being encrypted correctly because when I decrypt the same file with the same parameters, I get my input back.

I also tried an online tool to verify the result provided in the online document, extranet.cryptomathic.com which also gives the correct output.

How can I view the output in the format provided in the AESAVS document? Is the method that I have applied for encrypting the plaintext file correct or am I missing something here?

Improve this question

2 Answers 2

Reset to default
4

The input and output files should contain the binary data while the IV and KEY arguments should be hexadecimal data. But, you probably have put the hexadecimal data (f34481ec3cc627bacd5dc3fb08f273e6) into the input file and thus created an input file consisting of 32 ASCII characters instead of 16 (binary) bytes.

If done correctly it works.
First decode the hex string into binary, i.e. 32 byte hex into 16 byte binary data:

$ perl -e 'print pack(q[H*],q[f34481ec3cc627bacd5dc3fb08f273e6])'  > in.txt

Then run the encryption. Note that I've additionally used the -nopad option in the encryption because otherwise openssl adds an additional empty 16 bytes block to pad the input to the next 16 byte boundary.

$ openssl aes-128-cbc -nopad -e -in in.txt -out out.txt \
  -K  00000000000000000000000000000000 -iv 00000000000000000000000000000000 -p -nosalt

And finally encode the binary output (16 bytes) into a hex string so that you can compare it to the expected result:

$ perl -e 'local $/; print unpack(q[H*],<>),"\n"' < out.txt
0336763e966d92595a567cc9ce537f5e
Improve this answer
6
  • Thank you so much! This works like a charm! You are correct i was giving the incorrect input. just for reference/ better understanding, is this mentioned somewhere in the OpenSSL documentation which states explicitly that the input should contain binary data? Because i could not find it anywhere maybe thats why i was giving it input in an incorrect format.
    – Hussain Ali Akbar
    Commented Jan 2, 2018 at 10:28
  • @HussainAliAkbar: Using the plain(unencoded) data is actually the expected case and thus does not need to be mentioned explicitly. Only exceptions from this need to be mentioned and that's why it is documented that IV and key are expected in hex encoding.
    – Steffen Ullrich
    Commented Jan 2, 2018 at 10:46
  • Quick question: openssl is giving incorrect output for key=e234cdca2606b81f29408d5f6da21206, IV=00000000000000000000000000000000, PLAINTEXT=00000000000000000000000000000000. I cross checked with the online tool again which gives me the correct output but openssl gives "fff60a". I cant seem to figure out what could be the problem here. I tried playing with the -nopad flag as well but that doesn't seem to be the problem here. Any leads? Thanks!
    – Hussain Ali Akbar
    Commented Jan 2, 2018 at 14:38
  • @HussainAliAkbar: OpenSSL worked correctly. The line I gave to encode the output to hex did not account for newline characters in the output which occurred in this case. Fixed in the answer.
    – Steffen Ullrich
    Commented Jan 2, 2018 at 18:42
  • It works! Thank you once again. I guess i need to dive into perl for this in order to get a better understanding.
    – Hussain Ali Akbar
    Commented Jan 3, 2018 at 9:56
2

This can be done in one line, without using files to store the plaintext input of ciphertext output, like so:

echo -n 'f34481ec3cc627bacd5dc3fb08f273e6' | xxd -r -p | openssl aes-128-cbc -nopad -e -K  00000000000000000000000000000000 -iv 00000000000000000000000000000000 -nosalt | xxd -p

This produces:

0336763e966d92595a567cc9ce537f5e
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .