ECC·Diffie-Hellman·KEM 차이: 공개키로 공유 비밀을 만드는 방법

1장 개념과 보호 목표#

ECC는 타원곡선 수학을 사용하는 공개키 기술군이며 ECDH는 키 합의, ECDSA는 서명에 사용됩니다. Diffie-Hellman은 통신 양쪽이 공개값을 교환해 공유 비밀을 계산하는 방식이고 KEM은 캡슐화와 역캡슐화로 공유 비밀을 설정하는 방식입니다.

2장 원리와 구분#

교육용 DH에서 p=23, g=5, 비밀값 a=6, b=15를 고르면 공개값은 각각 8과 19이며 양쪽 공유값은 2입니다. 실제 시스템에서는 표준 파라미터·공개값 검증·난수 생성이 필요합니다. 공유값은 KDF에 넣어 실제 용도별 키로 유도합니다. 인증되지 않은 DH는 중간자 공격을 막지 못합니다.

3장 비교와 판단 기준#

기술	역할	별도로 필요한 조건
ECDH·DH	양쪽 공개값으로 비밀 합의	상대 인증·공개값 검증·KDF
ECDSA	타원곡선 기반 서명	난수·서명 검증·키 보호
KEM	캡슐화·역캡슐화로 비밀 설정	인증된 프로토콜과 키 유도
ElGamal	DH 계열 공개키 암호	실제 스킴의 보안·변조 조건

4장 공개키 기술의 이름과 기능을 구분한다#

ECC는 타원곡선 위의 연산을 이용하는 기술의 기반이고 ECDH는 그 기반으로 공유 비밀을 만드는 방식입니다. ECDSA는 같은 기반을 서명에 사용하는 예입니다. ECC라는 이름을 봤다고 암호화·서명·키 합의의 기능이 모두 같은 절차로 제공되는 것은 아닙니다. 프로토콜에서 어떤 기능으로 쓰는지부터 확인합니다.

DH는 양쪽이 비밀값을 갖고 공개값을 교환하는 키 합의입니다. KEM은 상대의 공개키로 공유 비밀과 캡슐화 값을 만들고 상대가 비밀키로 복원하는 구조입니다. 어느 것도 키 설정의 결과만으로 애플리케이션 데이터의 접근 권한을 완성하지는 않습니다.

5장 작은 수 DH에서 공개값을 만드는 단계#

교육용으로 p=23, g=5를 공유합니다. A는 비밀값 a=6을 고르고 A의 공개값은 5^6 mod 23=8입니다. B는 b=15를 고르고 공개값은 5^15 mod 23=19입니다. 비밀값 6과 15는 보내지 않고 공개값 8과 19를 교환합니다. 실제 사용에는 안전한 그룹과 검증된 구현을 사용합니다.

공유 파라미터: p=23, g=5
A의 비밀 a=6 → 공개값 A=8
B의 비밀 b=15 → 공개값 B=19
교환되는 값: 8과 19
교환하지 않는 값: 6과 15

6장 상대 공개값으로 같은 결과를 얻는 이유#

A는 B의 공개값에 자신의 비밀 지수를 적용해 19^6 mod 23=2를 얻습니다. B는 8^15 mod 23=2를 얻습니다. 두 계산은 모두 g^(ab) mod p의 관계를 갖기 때문에 결과가 같습니다. 하지만 이 예시의 수가 너무 작아 보안은 제공하지 않습니다.

sequenceDiagram
 participant A as 참여자 A
 participant B as 참여자 B
 Note over A,B: 교육용 p=23, g=5
 A->>A: 비밀 6, 공개값 8
 B->>B: 비밀 15, 공개값 19
 A->>B: 공개값 8
 B->>A: 공개값 19
 A->>A: 19의 6승 mod 23 = 2
 B->>B: 8의 15승 mod 23 = 2

7장 중간자는 수학을 깨지 않고도 끼어들 수 있다#

인증 없는 공개값 교환에서는 중간자가 A에게 자신의 값을 보내고 B에게도 다른 값을 보낼 수 있습니다. A와 중간자, 중간자와 B가 각각 다른 공유 비밀을 갖는 연결이 만들어질 수 있습니다. DH 계산이 틀린 것이 아니라 공개값을 보낸 상대의 신원을 확인하지 않은 문제입니다.

프로토콜은 인증서와 서명, 사전 공유 비밀 등의 규약으로 상대와 대화 문맥을 연결합니다. 인증서가 존재하는 것뿐 아니라 이름·체인·서명·대화 기록의 검증이 실제로 수행되어야 합니다.

flowchart LR
 A["A"] -->|"인증 없는 공개값"| M["중간자"]
 M -->|"다른 공개값"| B["B"]
 A --> X["A와 중간자의 비밀"]
 M --> X
 M --> Y["중간자와 B의 비밀"]
 B --> Y

8장 ECDH의 곡선과 공개점 검증#

타원곡선 기반 방식에서는 선택한 곡선·인코딩·공개점의 처리 규칙이 중요합니다. 서로 다른 그룹의 값을 섞거나 잘못된 입력을 받아들이면 키 설정의 가정이 깨질 수 있습니다. 직접 점 연산을 조립하기보다 해당 프로토콜과 라이브러리의 검증 기능을 사용합니다.

같은 비트 길이의 RSA·ECC 키를 같은 보안 강도로 비교하지 않습니다. 공격 구조와 파라미터가 다르기 때문입니다. 성능과 메시지 크기는 실제 지원 환경에서 측정하고 보안 강도는 관련 기준에 맞춰 판단합니다.

9장 공유 비밀을 그대로 암호키로 쓰지 않는 이유#

키 설정의 출력은 KDF에 연결해 암호화·인증·방향별 키로 유도합니다. KDF 입력에는 프로토콜이 정한 문맥을 넣어 같은 비밀이 다른 연결이나 기능에서 섞이지 않도록 합니다. 해시 한 번을 임의로 적용하는 것과 규약이 정한 키 일정은 다릅니다.

공유 비밀
  + 프로토콜 문맥
  + 대화 기록 또는 정해진 추가 입력
  → KDF
  → 송신 키 / 수신 키 / 필요한 파생 비밀

10장 임시 키와 장기 인증키를 분리한다#

ECDHE의 임시 비밀을 연결마다 새로 생성하고 적절히 폐기하면 장기 인증키가 나중에 노출되어도 과거 연결 비밀의 보호에 기여할 수 있습니다. 임시 비밀을 재사용하거나 로그·덤프에 장기간 남겨 두면 기대한 조건이 약해질 수 있습니다.

전방향 안전성은 알고리즘 약어만으로 확보되는 성질이 아닙니다. 인증·키 설정 모드·임시 비밀의 생성·보존·폐기와 세션 재개 조건을 함께 확인해야 합니다.

11장 KEM의 두 연산과 데이터 암호화#

캡슐화는 수신자 공개키로 공유 비밀과 캡슐화 값을 만들고, 역캡슐화는 수신자의 비밀키와 그 값을 이용해 비밀을 복원합니다. 이를 데이터 암호화와 결합하면 공유 비밀에서 DEK를 유도하고 문서 자체는 AEAD로 보호하는 구조가 됩니다.

flowchart LR
 P["수신자 공개키"] --> E["캡슐화"]
 E --> C["캡슐화 값"]
 E --> S["송신자 공유 비밀"]
 C --> D["비밀키로 역캡슐화"]
 D --> R["수신자 공유 비밀"]
 S --> K["KDF와 AEAD"]
 R --> K

12장 하이브리드 키 설정은 정해진 결합 규칙을 따른다#

기존 방식과 PQC를 결합하려는 경우 두 비밀을 단순히 이어 붙이는 자체 규칙보다 프로토콜이 정한 입력·협상·결합·실패 규칙을 사용합니다. 각 구성의 파라미터, 호환성, 메시지 크기와 다운그레이드 처리도 함께 검토합니다.

KEM이라는 인터페이스 이름은 양자내성의 동의어가 아닙니다. 사용하는 알고리즘과 보안 가정을 확인해야 합니다. 표준 알고리즘을 사용했다는 사실도 전체 프로토콜이 인증되고 안전하게 운영된다는 결론과 구분합니다.

13장 키 설정을 검증할 질문#

질문	확인할 자료	실패할 때의 영향
상대 공개값은 인증되는가?	인증·대화 검증 흐름	중간자 연결 가능성
임시 비밀을 재사용하는가?	생성·수명·폐기	전방향 안전성 조건 약화
KDF 문맥이 일치하는가?	규약·테스트 벡터	키 불일치·문맥 혼동
미지원 그룹을 어떻게 처리하는가?	협상·오류 정책	우회·약한 구성 선택
키가 로그에 남는가?	로그·덤프·추적 설정	세션 비밀 노출

정상 두 참여자의 결과 일치뿐 아니라 잘못된 공개값·인증 실패·중단·재시도를 시험합니다. 계산 성공과 의도한 상대와의 안전한 연결을 다른 검증 목표로 두면 놓치는 문제를 줄일 수 있습니다.

14장 적용 사례와 운영 방법#

임시 키를 사용하는 인증된 ECDHE는 장기 개인키가 나중에 노출되어도 과거 세션을 보호하는 전방향 안전성에 기여합니다. ElGamal은 DH 계열 수학을 활용하는 확률적 공개키 암호지만 원시 방식의 변조 가능성 등을 고려해야 합니다. ML-KEM 같은 KEM도 상대 인증을 자동으로 제공하지 않습니다.

15장 ECC·DH·KEM을 같은 단계에서 비교하면 혼동된다#

ECC는 타원곡선을 이용하는 공개키 기술의 기반입니다. ECDH는 타원곡선 기반 키 합의, ECDSA는 서명이며 같은 역할이 아닙니다. Diffie-Hellman은 양쪽의 비밀값과 공개값으로 공유 비밀을 만드는 방식이고, KEM은 캡슐화 값과 수신자의 비밀키로 공유 비밀을 복원하는 인터페이스입니다. KEM이란 이름만으로 양자내성을 보장하지는 않습니다.

공유 비밀은 그대로 암호키로 쓰기보다 KDF에 연결해 용도별 키를 유도합니다. 프로토콜 버전·참여자·대화 문맥을 함께 결합하고 송신·수신 방향의 키를 분리해야 다른 연결이나 다른 용도의 비밀이 섞이지 않습니다. 인증 없는 키 합의는 중간자가 각각 다른 공유 비밀을 만들 수 있습니다.

16장 작은 수 DH 예제에서 빠진 인증을 찾기#

p=23, g=5이고 양쪽 비밀값이 6과 15이면 공개값은 각각 8과 19, 공유 결과는 2입니다. 이 계산은 두 참여자의 결과가 같다는 사실만 보여 줍니다. 공개값 8과 19가 정말 의도한 상대의 값인지까지 증명하지는 않습니다. 실제 통신에서는 인증서·서명·사전 공유 비밀 등 프로토콜이 정한 인증 절차가 필요합니다.

전방향 안전성을 검토할 때는 임시 키의 생성과 폐기, 장기 인증키와의 분리를 확인합니다. 이름에 ECDHE가 있다고 해도 구현이 임시 비밀을 재사용하거나 보관하는 방식을 검토해야 합니다.

17장 적용 전 확인할 사항#

키 설정과 상대 인증을 함께 설계한다
공유 비밀에서 용도별 키를 KDF로 유도한다
프로토콜·라이브러리가 지정한 공개값 검증을 적용한다

18장 자주 묻는 질문#

ECC의 키가 짧으면 RSA보다 약한가요?#

서로 다른 수학 문제를 사용하므로 키 길이를 직접 비교하면 안 됩니다. 고전적 공격 기준에서 요구되는 보안 강도를 맞춰 알고리즘별 파라미터를 선택해야 합니다.

공개키 길이가 짧으면 더 약한 암호인가요?#

서로 다른 수학적 구조의 비트 길이를 직접 비교하면 안 됩니다. 보안 강도, 알고리즘 가정과 표준의 대응 관계를 기준으로 비교해야 합니다.

KEM으로 파일 전체를 암호화하나요?#

KEM의 주된 역할은 공유 비밀 설정입니다. 파일은 그 비밀에서 유도한 대칭키로 암호화하는 KEM과 데이터 암호화의 결합 구조를 사용합니다.