Во-первых, вы можете побеспокоиться о прокладке позже. Предоставление 0, как вы сделали, означает AES CBC без заполнения, и с этой конфигурацией вы должны увидеть свое сообщение очень хорошо. Хотя потенциально с некоторыми байтами заполнения в конце. Итак, остается:
- Вы неправильно загружаете ключ.
- Вы неправильно загружаете IV.
- Вы не правильно загружаете данные.
- Сервер делает то, чего вы не ожидаете.
Чтобы отладить это, вам нужно изолировать вашу систему. Вы можете сделать это, внедрив циклический тест, в котором вы одновременно шифруете, а затем расшифровываете данные, чтобы убедиться, что вы загружаете все правильно. Но это может ввести в заблуждение. Даже если вы сделаете что-то не так (например, загрузите ключ в обратном порядке), вы все равно сможете расшифровать то, что зашифровали, потому что вы делаете это одинаково неправильно с обеих сторон.
Так что вам нужно проверить против Known Answer Tests (КАЦ). Вы можете найти официальные KAT в записи AES в Википедии. Но так уж получилось, что я разместил здесь другой ответ на ТАК, что мы можем использовать.
Учитывая этот ввод:
KEY: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f
IV: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
PLAIN TEXT: encrypt me
CIPHER TEXT: 338d2a9e28208cad84c457eb9bd91c81
Проверьте с помощью сторонней программы, что вы можете расшифровать зашифрованный текст и получить обычный текст.
$ echo -n "encrypt me" > to_encrypt
$ openssl enc -in to_encrypt -out encrypted -e -aes-256-cbc \
> -K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
> -iv 0000000000000000
$ hexdump -C encrypted
00000000 33 8d 2a 9e 28 20 8c ad 84 c4 57 eb 9b d9 1c 81 |3.*.( ....W.....|
00000010
$ openssl enc -in encrypted -out plain_text -d -aes-256-cbc \
> -K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
> -iv 0000000000000000
$ hexdump -C plain_text
00000000 65 6e 63 72 79 70 74 20 6d 65 |encrypt me|
0000000a
Итак, теперь попробуйте расшифровать этот тест с известным ответом в своей программе. Обязательно включите заполнение PKCS7, потому что это то, что я использовал в этом примере. В качестве упражнения расшифруйте его без заполнения и убедитесь, что результат тот же, за исключением того, что у вас есть байты заполнения после текста «зашифровать меня».
Внедрение KAT — большой шаг. В нем говорится, что ваша реализация правильная, но ваши предположения о поведении сервера неверны. И тогда пришло время начать подвергать сомнению эти предположения...
(И PS, эти варианты, которые вы упомянули, не являются взаимоисключающими. ECB означает отсутствие IV, а CBC означает, что у вас есть IV. Никакого отношения к заполнению.)
Хорошо, я знаю, что сказал, что это упражнение, но я хочу доказать, что даже если вы шифруете с дополнением и расшифровываете без заполнения, вы не получаете мусора. Таким образом, учитывая KAT, который использовал заполнение PKCS7, мы расшифровываем его с опцией без заполнения и получаем читаемое сообщение, за которым следует 06, используемый в качестве байта заполнения.
$ openssl enc -in encrypted -out plain_text -d -aes-256-cbc \
-K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
-iv 0000000000000000 -nopad
$ hexdump -C plain_text
00000000 65 6e 63 72 79 70 74 20 6d 65 06 06 06 06 06 06 |encrypt me......|
00000010
$
person
indiv
schedule
09.02.2011
