Зачем использовать Deffie Hellmen (Key Exchange) вместо шифрования симметричного сеансового ключа с помощью открытого ключа сервера или клиента?

Зачем использовать Deffie Hellmen (Key Exchange) вместо шифрования симметричного сеансового ключа с помощью открытого ключа сервера или клиента?

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

решение1

Такие методы обмена ключами существуют – действительно, долгое время это былоначальныйспособ обмена ключами в SSL/TLS, и подобная схема была единственным доступным методом обмена в SSHv1 (который сейчас устарел).

Однако обе системы мигрировалиотобмен ключами на основе шифрования с DH.

Описанный вами механизм имеет одну серьезную проблему: если закрытый ключ сервера украден, его можно использовать для расшифровкикаждое соединениекоторый был ранее создан или когда-либо будет создан с помощью этой пары ключей. (Другими словами, этоне хватаетпрямая секретность.)

Учитывая, что раньше сертификаты HTTPS выдавались на 5 или даже 10 лет, а SSH — на прямуюполагаетсяЕсли ключи хоста не меняются после создания, это может быть довольно рискованно. (Например, если тот же злоумышленник отслеживал сетевой трафик в центре обработки данных... или если вы живете в стране, которая участвовала в таких программах наблюдения, как PRISM или XKeyscore.)

(SSHv1 пытался смягчить это, генерируя эфемерные ключи RSA для обмена ключами, но это полностью сводит на нет преимущество наличия «известного» ключа сервера для шифрования. А поскольку генерация ключей RSA требует значительного объема обработки, она выполнялась только каждые несколько часов, а эфемерные ключи были ограничены 768 битами.)

Другая проблема заключается в том, что требуется возможность шифрованияограничивает ваш выбор ключевого алгоритмаЕсли я правильно понимаю, асимметричные цифровые подписи (для аутентификации обмена ключами DH) реализовать проще, чем асимметричное шифрование, даже для тех алгоритмов, которыемогсделать и то, и другое — и то не все могут.

Например, ключи EC не могут использоваться для шифрования напрямую, только для подписи и обмена ключами. Существуют схемы, которые реализуют шифрование с ключами EC (например, ECMQV), но они на самом делена основе обмена ключами ECDH.Тогда можно просто использовать DH.

Связанный контент