Сначала вы можете позаботиться о заполнении позже. Предоставление 0, как вы сделали, означает AES CBC без заполнения, и с этой конфигурацией вы должны видеть свое сообщение очень хорошо. Albiet потенциально с некоторыми байтами заполнения в конце. Так что выходит:
- Вы неправильно загружаете ключ.
- Вы неправильно загружаете IV.
- Вы неправильно загружаете данные.
- Сервер делает что-то, чего вы не ожидаете.
Чтобы отладить это, вам нужно изолировать вашу систему. Вы можете сделать это, выполнив тест обратной петли, в котором вы оба шифруете, а затем дешифруете данные, чтобы убедиться, что вы загружаете все правильно. Но это может вводить в заблуждение. Даже если вы делаете что-то не так (например, загружаете ключ назад), вы все равно сможете расшифровать то, что вы зашифровали, потому что вы делаете это одинаково неправильно с обеих сторон.
Так что вам нужно проверить против Known Answer Tests (KATs). Вы можете посмотреть официальные KAT-файлы в AES википедии . Но так получилось, что я разместил другой ответ здесь, на SO, который мы можем использовать.
С учетом этого ввода:
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, потому что это то, что я использовал в этом примере. В качестве упражнения расшифруйте его без заполнения и убедитесь, что результат такой же, за исключением того, что у вас есть байты заполнения после текста «encrypt me».
Внедрение KAT - большой шаг. Это говорит о том, что ваша реализация верна, но ваши предположения о поведении сервера неверны. И тогда пришло время начать подвергать сомнению эти предположения ...
(И P.S., те опции, которые вы упомянули, не являются взаимоисключающими. ECB означает отсутствие IV, а CBC означает, что вы имеете IV. Никакого отношения к заполнению.)
Хорошо, я знаю, что сказал, что это упражнение, но я хочу доказать это, даже если вы шифруете с отступом
и расшифровывать без заполнения, вы не получите мусор. Поэтому, учитывая KAT, который использовал заполнение PKCS7, мы расшифровываем его с помощью опции no padding и получаем читаемое сообщение, за которым следует 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
$