две реализации AES генерировали разные результаты шифрования

У меня есть приложение, которое использует "libgcrypt" с открытым исходным кодом для шифрования/дешифрования блока данных (32 байта). Теперь я собираюсь использовать Microsoft CryptAPI для его замены. Моя проблема заключается в том, что подходы libgcrypt и cryptApi генерируют разное содержимое зашифрованного текста, поскольку я использую один и тот же алгоритм AES-256 в режиме CFB, один и тот же ключ и один и тот же IV, хотя зашифрованный текст может быть расшифрован их собственными соответственно.

Может кто подскажет в чем проблема? Спасибо.


c++ encryption aes
person YCL    schedule 22.03.2010    source источник

Ответы (5)


arrow_upward
2
arrow_downward

Предполагают ли они разный порядок следования байтов или назначают байты в ключе/IV в разном порядке?

Если предположения о порядке следования байтов отличаются, вам может потребоваться изменить порядок байтов в ключе, IV и/или открытом тексте, чтобы получить совпадающие результаты. Например, если вы предоставляете байты в порядке abcdefgh, вам может потребоваться переключить его на 'dcbahgfe', чтобы все заработало.

person David M    schedule 22.03.2010
comment
Я считаю, что у них разный порядок байтов. - person YCL; 22.03.2010

arrow_upward
1
arrow_downward

Для CFB есть дополнительный параметр, а именно «количество сдвига» на каждой итерации. На странице Википедии о CFB есть некоторая информация. А именно, вы шифруете x битов для каждого шифрования блока, где x — любое значение от 1 до размера блока (128 для AES). Я подозреваю, что в вашем коде Microsoft CryptoAPI и libgcrypt не используют одно и то же значение для x.

Как поясняется в документации для CryptSetKeyParam() , Windows по умолчанию использует x=8 (т. е. по одному байту за раз). Это параметр KP_MODE_BITS. С другой стороны, libgcrypt по умолчанию x=n для n-битного блочного шифра (например, x=128 для AES). Я не уверен, что libgcrypt можно убедить использовать другое значение.

person Thomas Pornin    schedule 22.03.2010
comment
Вызов этого CryptSetKeyParam() путем передачи значения больше 64 всегда возвращает 0 (сбой), и этот вызов функции, кажется, не влияет на содержимое зашифрованного текста, когда значение битов режима не превышает 64 (вероятно, потому что тот факт, что мне нужно только для вызова функции шифрования один раз в моем приложении). - person YCL; 23.03.2010

arrow_upward
1
arrow_downward

Я думаю, что проблема связана с размером блока. Как вы сказали, вы используете 32 байта в качестве размера блока, убедитесь, что размер блока у обоих одинаковый и поддерживается. Потому что размер некоторых блоков библиотеки фиксирован для Aes как 16 байт.

person sukumar    schedule 26.10.2012

arrow_upward
0
arrow_downward

Какова длина вашего ключа и IV? Отличаются ли зашифрованные тексты, если длина открытого текста составляет ровно 256 бит?

person Nike    schedule 22.03.2010
comment
Я понимаю, к чему вы клоните, но в режиме CFB шифр должен эффективно работать как потоковый шифр без заполнения... - person David M; 22.03.2010
comment
Длина ключа 32 байта, а IV 16 байт. Шифрованные тексты различаются независимо от размера открытого текста. - person YCL; 22.03.2010
comment
Переупорядочивание байтов в ключе, IV и/или открытом тексте и проверка всех их комбинаций. Никто не работает. - person YCL; 22.03.2010

arrow_upward
0
arrow_downward

У меня такая же проблема, но с другой библиотекой. Я заметил одну вещь в этой библиотеке; Если я передаю входной байт меньше 32 байтов, в этом случае он показывает мне, что оба являются одними и теми же зашифрованными данными.

Это то, что происходит в вашем случае? Если это так, значит, проблема в механизме заполнения.

person sukumar    schedule 22.10.2012