Каково распределение вероятностей значений проверки ключей 3DES?

Мы не знаем, но твердо верим, что в вычислительном отношении он неотличим от униформы.

Являются ли значения проверки ключей, которые вы используете, 64-битными (насколько мне известно, для 3DES нет стандартного «алгоритма проверки ключей»); если да, то 64 бита явно недостаточно, если возможны коллизионные атаки, и сомнительная ценность, если возможны атаки прообразом (то есть найти второй ключ с тем же значением проверки, что и этот).

(Еще) большая проблема со стандартными KCV PKCS # 11 заключается в том, что они содержат шифрование всех нулевых входных сообщений. Теперь, если вы выберете режим CTR, вы обнаружите, что начальное значение счетчика с нулевым одноразовым номером (и, следовательно, с нулевым счетчиком) также равно нулю. Другими словами: вы напрямую пропускаете байты ключевого потока. Они должны были просто использовать одностороннюю функцию, такую ​​как SHA-1.

Я думаю, что комментарий пончо довольно хорошо освещает вопрос; если это применимо, зависит от вашего варианта использования (например, сколько байтов хранится в KCV, может ли злоумышленник инициировать использование многих ключей и т. д.). Обратите внимание, что 3DES имеет некоторые недостатки, присущие небольшому размеру блока. Я бы предпочел использовать одностороннюю функцию с большим выходным размером. Даже SHA-1, HMAC-SHA-1 или родственный KDF будут намного лучше, чем KCV (160 бит против 64 бит), даже с тройным DES с двумя ключами.Функция на основе SHA-256 была бы даже лучше, но я предполагаю, что вы ограничены устаревшими алгоритмами, если вам все еще приходится использовать 3DES...

Спасибо, это имеет смысл. Партнеру, который отправляет мне ключи, требуется 3DES, но я могу использовать SHA-256 для ключа. Оказывается, я собираюсь использовать другой дизайн. Нет никакой гарантии, что партнер не отправит мне ключ отправки дважды, чтобы использовать его в двух разных случаях, что делает наличие идентификатора для ключа бесполезным.

Этот вопрос на других языках: