베어 Diffie–Hellman 계산은 양쪽이 공개값으로 같은 공유 비밀을 만들게 합니다. 그 결과만으로 공개값을 보낸 사람의 신원까지 확인하지는 않습니다. 공격자가 공개값을 바꿔 전달할 수 있고 각 통신자와 별도의 비밀을 합의하면 중간에서 메시지를 풀고 다시 암호화할 수 있습니다.
키 합의, 키 확인, 상대 인증은 서로 다른 질문입니다. 이 글의 p=23 예시는 손계산용이며 운영에 쓸 소수·곡선·암호 매개변수가 아닙니다. 실제 프로토콜은 신원과 공개 키를 서명·인증서 같은 방법으로 결합하고, 인증 조건과 키 확인을 명시해야 합니다.
공개값을 주고받으면 같은 비밀이 계산됩니다
Diffie–Hellman 키 합의의 작은 수학 모델을 보겠습니다. 교육용으로 소수 p=23과 생성원 g=5를 고정하고, 앨리스의 비밀 지수 a=6, 밥의 비밀 지수 b=15라고 둡니다. 앨리스는 A=gᵃ mod p, 밥은 B=gᵇ mod p를 계산해 서로 공개합니다. 각자는 자기 비밀 지수와 받은 공개값을 거듭제곱해 공유값을 구합니다.
| 단계 | 연산 | 결과 |
|---|---|---|
| 앨리스 공개값 | 5⁶ mod 23 | 8 |
| 밥 공개값 | 5¹⁵ mod 23 | 19 |
| 앨리스 공유값 | 19⁶ mod 23 | 2 |
| 밥 공유값 | 8¹⁵ mod 23 | 2 |
왜 마지막 값이 같을까요? 앨리스는 Bᵃ=(gᵇ)ᵃ=gᵃᵇ를, 밥은 Aᵇ=(gᵃ)ᵇ=gᵃᵇ를 계산합니다. 따라서 두 계산은 같습니다. 실제 알고리즘은 안전한 군·곡선과 표준 키 도출 절차를 사용하지만, 여기서는 지수 법칙만 확인합니다. 소수 23은 가능한 값을 쉽게 전부 시험할 수 있으므로 안전하지 않습니다.
계산 결과가 같다는 사실은 신원 증명이 아닙니다
키 합의는 두 참여자가 공유한 비밀 값을 계산하는 작업입니다. 인증은 상대가 자신이 주장하는 사람 또는 시스템인지 확인하는 작업입니다. 둘은 함께 구성될 수 있지만 같은 기능은 아닙니다. 공개값 A와 B만 확인하고 어떤 신원이 보냈는지 검증하지 않으면, 수신자는 값의 출처를 알 수 없습니다. NIST의 키 설정 지침은 Diffie–Hellman 계열을 키 설정 방식에 포함하고, 디지털 인증 지침은 네트워크 주체가 이전에 인증된 구독자인지 확인하는 별도 과정을 다룹니다.
중간자 M이 앨리스와 밥 사이의 공개값을 바꿔 보낸다고 가정합시다. M은 앨리스 쪽에 자신이 고른 공개값 X를 보내고, 밥 쪽에는 별도로 고른 공개값 Y를 보냅니다. 앨리스는 M과 공유하는 키 Kₐ를 만들고 밥은 M과 공유하는 다른 키 Kᵦ를 만듭니다. M은 앨리스의 암호문을 Kₐ로 풀고, 내용을 밥에게 전달할 때 Kᵦ로 다시 보호할 수 있습니다. 앨리스와 밥 각각은 상대와 공유한다고 믿지만 실제로는 M을 포함한 두 합의가 형성된 셈입니다.
| 질문 | 계산만 확인한 경우 | 추가로 필요한 연결 |
|---|---|---|
| 양쪽이 같은 키를 계산했나? | 키 합의 방식이 조건대로 실행됐는지 확인 | 키 확인 절차가 있는지 확인 |
| 공개값을 보낸 사람이 의도한 상대인가? | 공개값의 수학적 형식만으로 알 수 없음 | 인증서·서명·사전 공유 키 등 신원에 묶인 인증 |
| 교환 기록이 바뀌지 않았나? | 키가 계산된 사실만으로는 부족 | 핸드셰이크 transcript와 인증 값의 결합 확인 |
프로토콜을 읽을 때 세 질문을 분리합니다
- 공개 매개변수와 두 비밀 지수를 확인하고 공개값을 직접 계산합니다.
- 양쪽에서 계산한 공유 비밀이 대수적으로 같은지 식으로 검산합니다.
- 상대의 공개값이 어떤 신원에 연결되는지, 그 연결을 누가 검증하는지 찾습니다.
- 키 확인이 있다면 그것이 키 일치를 확인하는지, 신원 인증까지 포함하는지 구분합니다.
- 인증 값이 공개값과 세션의 맥락에 묶이지 않아 바꿔치기에 취약한 곳이 없는지 봅니다.
인증서가 등장한다고 모든 문제가 자동으로 해결되는 것도 아닙니다. 인증서의 이름과 용도를 확인하고, 신뢰 기준을 검증하며, 인증 서명이 실제 키 교환과 같은 세션에 묶였는지 확인해야 합니다. 키 확인 메시지는 양쪽이 같은 키를 가진다는 증거가 될 수 있지만, 그 키가 누구와 공유된 것인지는 별도 인증에 달려 있습니다. 이 글은 특정 프로토콜이나 제품의 구현 결함을 판정하지 않습니다. 실제 핸드셰이크를 검토한다면 신원 검증과 키 합의 메시지가 어떤 서명 또는 인증 값에 함께 포함되는지 원문 규격에서 추적하세요.
회상 연습: 값은 같지만 누구의 키인지 모릅니다
교육용 문제입니다. p=23, g=5, a=6, b=15이며 공개값은 각각 8과 19입니다. 양쪽 공유값이 2로 같다는 사실을 확인했습니다. 이 결과만으로 밥이 실제 통신 상대였다고 결론 내릴 수 있나요? 공격자가 두 공개값을 바꾸어 별도 키를 만들 수 있는 조건과 함께 답하세요.
아니요. 19⁶ mod 23과 8¹⁵ mod 23은 모두 2이므로 키 합의 계산은 일치합니다. 하지만 공개값 출처를 검증하지 않으면 중간자가 앨리스 쪽과 밥 쪽에 서로 다른 공개값을 주고 두 개의 공유 키를 만들 수 있습니다. 따라서 키 합의 결과와 상대 인증 증거를 따로 확인해야 합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
p=23, g=5, a=6, b=15에서 공개값 8·19로 공유값 2가 나왔다. 이 일치만으로 밥의 신원을 인증했다고 할 수 있는가? 이유를 답하라.
정답과 해설 확인
그럴 수 없습니다. 값 2의 일치는 두 공개값으로 같은 공유 비밀을 계산했다는 뜻입니다. 공개값의 전달자를 인증하지 않으면 중간자가 두 통신자와 각각 다른 공유 키를 만들 수 있습니다.NIST SP 800-56A Rev. 3는 Diffie–Hellman을 포함한 키 설정 방식을 다룹니다. SP 800-63B-4는 네트워크 주체 인증의 목적을 별도로 정의합니다. Rev. 3는 2026년에 업데이트 결정이 공개되었으므로, 이 글은 확인한 현재 최종판의 범위로만 설명합니다.