Ahhh!So, a 15 byte block (or ends with a 15 byte after multiples of 16 bytes) would use a 0x01 in the last position...?And a whole multiple of 16 blocks would have an extra block filled with 0x0f's...?My initial testing now looks like I can get it to work.Thanks!-Scott Weber
Original Mes
Here is an update. I have 2 code fragments, one that works, AND ONE THAT DOESN'T.The ONLY difference is the content of the 16 bytes of clear text being encoded. Both are decrpyted with the following command:openssl aes-256-cbc -in output.bin -K 31313131313131313131313131313131
Nice catch. but no, sorry.The function AES_set_encrypt_key(key32, 256, &aeskey) contains the key length (32 bytes X 8 bits).I repeated the test from Marek changing the keys and IV to my values, and his demo still works.So I am continuing my side by side test to see what the difference is. So far
Thanks for your reply, but that's not doing it.I manually padded the input in the C code with spaces. Then I manually padded the input file with spaces. Now both cleartexts are exactly 16 bytes long.The output from the openssl executable is now 32 bytes...? Where did it decide to do that?The API
(resent, as I never saw this come through the list server)I am looking for some assistance. This should be really easy. But it's not working. Any quick advice I can get would be appreciated.When I use the API, I get a different cypher text then I get from the command line.And the command line ap
