%EC%9D%84%20%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%20%EC%9D%B4%EC%9C%A0%EB%8A%94%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F.png)
클라이언트가 대칭 세션 키를 생성한 다음 서버의 공개 키로 암호화하여 서버로 보내는 경우 서버만 개인 키로 암호화된 세션 키를 해독할 수 있으며 그 반대의 경우도 마찬가지입니다.
답변1
이러한 키 교환 방법이 실제로 존재합니다. 실제로 오랫동안 이것이 사용되었습니다.주요한SSL/TLS에서 키가 교환되는 방식과 유사한 체계가 SSHv1(현재는 사용되지 않음) 내에서 사용 가능한 유일한 교환 방법이었습니다.
그러나 두 시스템 모두 마이그레이션되었습니다.~에서암호화 기반 키를 DH로 교환합니다.
설명하는 메커니즘에는 한 가지 중요한 문제가 있습니다. 서버의 개인 키를 도난당한 경우 이를 해독하는 데 사용할 수 있습니다.연결 하나하나이전에 만들어졌거나 해당 키 쌍으로 만들어질 예정입니다. (즉, 그것은부족하다순방향 비밀성.)
HTTPS 인증서는 5년, 심지어 10년 동안 발급되었고 SSH는 완전히 발급되었다는 점을 고려하면의지하다일단 생성된 호스트 키는 변경되지 않으므로 이는 상당히 위험할 수 있습니다. (예를 들어, 동일한 공격자가 데이터 센터의 네트워크 트래픽을 모니터링한 경우... 또는 PRISM 또는 XKeyscore와 같은 감시 프로그램에 참여한 국가에 거주하는 경우.)
(SSHv1은 키 교환 목적으로 임시 RSA 키를 생성하여 이를 완화하려고 시도했지만 이는 사물을 암호화하기 위해 "알려진" 서버 키를 갖는 이점을 완전히 무효화합니다. 그리고 RSA 키 생성에는 상당한 양의 처리가 필요하기 때문에 몇 시간마다만 수행되며 임시 키는 768비트로 제한되었습니다.)
또 다른 문제는 암호화 기능이 필요하다는 것입니다.키 알고리즘 선택을 제한합니다.. 내가 올바르게 이해했다면 비대칭 디지털 서명(DH 키 교환을 인증하기 위한)은 다음을 수행하는 알고리즘의 경우에도 비대칭 암호화보다 구현하기가 더 쉽습니다.~할 수 있었다두 가지 모두를 수행하십시오 – 모두가 할 수 있는 것은 아닙니다.
예를 들어 EC 키는 암호화에 직접 사용할 수 없으며 서명 및 키 교환에만 사용할 수 있습니다. EC 키(예: ECMQV)로 암호화를 구현하는 체계가 있지만 실제로는ECDH 키 교환을 기반으로 합니다.그렇다면 DH를 사용하는 것이 좋습니다.