서버나 클라이언트의 공개 키로 대칭 세션 키를 암호화하는 대신 Deffie Hellmen(키 교환)을 사용하는 이유는 무엇입니까?

서버나 클라이언트의 공개 키로 대칭 세션 키를 암호화하는 대신 Deffie Hellmen(키 교환)을 사용하는 이유는 무엇입니까?

클라이언트가 대칭 세션 키를 생성한 다음 서버의 공개 키로 암호화하여 서버로 보내는 경우 서버만 개인 키로 암호화된 세션 키를 해독할 수 있으며 그 반대의 경우도 마찬가지입니다.

답변1

이러한 키 교환 방법이 실제로 존재합니다. 실제로 오랫동안 이것이 사용되었습니다.주요한SSL/TLS에서 키가 교환되는 방식과 유사한 체계가 SSHv1(현재는 사용되지 않음) 내에서 사용 가능한 유일한 교환 방법이었습니다.

그러나 두 시스템 모두 마이그레이션되었습니다.~에서암호화 기반 키를 DH로 교환합니다.

설명하는 메커니즘에는 한 가지 중요한 문제가 있습니다. 서버의 개인 키를 도난당한 경우 이를 해독하는 데 사용할 수 있습니다.연결 하나하나이전에 만들어졌거나 해당 키 쌍으로 만들어질 예정입니다. (즉, 그것은부족하다순방향 비밀성.)

HTTPS 인증서는 5년, 심지어 10년 동안 발급되었고 SSH는 완전히 발급되었다는 점을 고려하면의지하다일단 생성된 호스트 키는 변경되지 않으므로 이는 상당히 위험할 수 있습니다. (예를 들어, 동일한 공격자가 데이터 센터의 네트워크 트래픽을 모니터링한 경우... 또는 PRISM 또는 XKeyscore와 같은 감시 프로그램에 참여한 국가에 거주하는 경우.)

(SSHv1은 키 교환 목적으로 임시 RSA 키를 생성하여 이를 완화하려고 시도했지만 이는 사물을 암호화하기 위해 "알려진" 서버 키를 갖는 이점을 완전히 무효화합니다. 그리고 RSA 키 생성에는 상당한 양의 처리가 필요하기 때문에 몇 시간마다만 수행되며 임시 키는 768비트로 제한되었습니다.)

또 다른 문제는 암호화 기능이 필요하다는 것입니다.키 알고리즘 선택을 제한합니다.. 내가 올바르게 이해했다면 비대칭 디지털 서명(DH 키 교환을 인증하기 위한)은 다음을 수행하는 알고리즘의 경우에도 비대칭 암호화보다 구현하기가 더 쉽습니다.~할 수 있었다두 가지 모두를 수행하십시오 – 모두가 할 수 있는 것은 아닙니다.

예를 들어 EC 키는 암호화에 직접 사용할 수 없으며 서명 및 키 교환에만 사용할 수 있습니다. EC 키(예: ECMQV)로 암호화를 구현하는 체계가 있지만 실제로는ECDH 키 교환을 기반으로 합니다.그렇다면 DH를 사용하는 것이 좋습니다.

관련 정보