Bonjour, > Le 9 oct. 2015 ? 12:20, karel-de-macil at wanadoo.fr a ?crit : > [?] > Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key > Key : 0x06a9214036b8a15b512e03d534120006 > IV : 0x3dafba429d9eb430b422da802c9fac41 > Plaintext : "Single block msg" > Ciphertext: 0xe353779c1079aeb82708942dbe77181a > > the command line i launch is the following > > :~/git/aes/openssl$ od -c clear3.txt > 0000000 S i n g l e b l o c k m s g > 0000020 > openssl enc -nosalt -aes-128-cbc -in clear3.txt -e -out test.enc -K 06a9214036b8a15b512e03d534120006 -iv 3dafba429d9eb430b422da802c9fac41 > > :~/git/aes/openssl$ od -x test.enc > 0000000 53e3 9c77 7910 b8ae 0827 2d94 77be 1a18 > 0000020 7cb9 5e82 781c 4651 2d54 6939 bc41 5de5 > 0000040 > > The first 16 bit are the answer given but what are the 16 following one ? Padding, so the decryption process knows how many useful octets were encrypted. In your case, since the block is full, padding adds another block. > > bellow that, my own program is AES-128 , not aes-128-cbc but for a msg of 16 bit only and a nul iv there should be no difference for what i understand. > > but when i use the following number found here : > > http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf > > PLAINTEXT: 00112233445566778899aabbccddeeff > KEY: > 000102030405060708090a0b0c0d0e0f > > round[10].output 69c4e0d86a7b0430d8cdb78070b4c55a > > i get the following > > :~/git/aes/openssl$ od -x clear2.txt > 0000000 1100 3322 5544 7766 9988 bbaa ddcc ffee > 0000020 > :~/git/aes/openssl$ openssl enc -nosalt -in clear2.txt -out encrypted.dat -e -aes-128-cbc -k 000102030405060708090a0b0c0d0e0f -iv 00000000000000000000000000000000 -k is not the same as -K. Cordialement, Erwann Abalea
