PQC II

쿠쿠 오늘은 PQC에 대해서 알아보겠습니다!

(2026-06-29에 진행한 UNKNOWN 세미나)

---

PQC

배경

• 안전한 통신에는 비밀과 신원이 둘 다 필요함
• 키 교환은 ‘비밀’, 서명은 ‘신원’을 담당함
• 공개키만으로는 ‘신원’을 알 수 없음 - 신원은 ‘CA의 서명’이 보증함
• 인증서에는 신원, 공개키, CA의 서명이 들어있음

👉 양자내성에는 ML-KEM과 ML-DSA가 둘 다 필요함

공개키/비밀키가 나와도 목표와 전송 데이터가 다름

→ 기준: 암호화는 데이터 보호, KEM은 키 합의, DSA는 출처 증명

ML-KEM 데이터 흐름

FIPS 203/204/205

표준	알고리즘	역할	설명
FIPS 203	ML-KEM	키 협의/공유 비밀	TLS 하이브리드 키 교환
FIPS 204	ML-DSA	전자서명	인증서·코드서명 전환
FIPS 205	SLH-DSA	해시 기반 전자서명	보수적 백업 선택지

ML-KEM

KeyGen

KeyGen 과정에서는 공개키(pk)와 비밀키(sk)를 생성함

• ρ(seed)를 이용하여 행렬 A를 생성
• 작은 값인 s와 e를 생성한

공개 계산값인 t = A·s + e 를 계산

 

👉 최종적으로 공개키 (pk) = (t, ρ), 비밀키(sk) = s 포함으로 구성됨

네트워크에서는 공개키만 전송되고 비밀키는 내부에만 저장됨

Encaps

상대방의 공개키(pk)를 이용해 다음 두 가지를 만듦

• ciphertext(ct)
• shared secret

여기서 중요한 점은 shared secret은 전송되지 않음

전송되는 것은 ciphertext뿐이며, shared secret은 양쪽이 각각 계산해서 얻음

Decaps

• 비밀키(sk)를 가진 쪽은 받은 ciphertext를 이용하여 원래의 임시 비밀(m')을 복원함
• 복원된 m'을 이용해 shared secret을 다시 계산함

즉 ciphertext → shared secret이 아니라 ciphertext → m 복원 → shared secret 생성

 

ML-KEM에서는 ciphertext 안에 shared secret이 저장되어 있는 것이 아님

ciphertext: shared secret을 다시 계산할 수 있도록 도와주는 정보

Decapsulation 과정에서는

v - sᵀu

와 같은 계산을 수행하여 원래의 메시지(seed)를 복원

m'
↓

shared secret

→ 복원 이후 생성

👉 따라서 shared secret은 ciphertext에서 직접 꺼내는 값이 아니라, 복원한 메시지로부터 새롭게 계산되는 값

ML-KEM 표준 크기

알고리즘	공개키	비밀키	ciphertext
ML-KEM-512	800B	1632B	768B
ML-KEM-768	1184B	2400B	1088B
ML-KEM-1024	1568B	3168B	1568B

ML-DSA 원리

Keygen

서명 public key / secret key 생성
public key는 검증자에게 공개

Sign

secret key로 transcript에
signature 생성
서버가 보냈다는 증거

Verify

public key로 signature 검증
본문이 1바이트 바뀌면 실패

ML-DSA 표준 크기

알고리즘	공개키	비밀키	Signature
ML-DSA-44	1312B	2560B	2420B
ML-DSA-65	1952B	4032B	3309B
ML-DSA-87	2592B	4896B	4627B

TLS에서 ML-KEM과 ML-DSA

TLS에서는 두 알고리즘이 서로 다른 역할을 함

 

1. ClientHello

→ ML-KEM 공개키 전송

2. ServerHello

→ ML-KEM ciphertext 전송

3. shared secret 생성

4. Certificate

→ ML-DSA 서명 검증

5. shared secret으로 HKDF 수행

6. AES-GCM으로 실제 데이터 암호화

 

👉 ML-KEM은 세션키 생성, ML-DSA는 서버 인증을 담당

기존 암호와 PQC 비교

키 교환 비교

X25519

• 공개키 작음
• 매우 빠름
• 양자 공격에는 취약

ML-KEM

• 공개키와 ciphertext가 큼
• 양자 안전

Hybrid

• X25519 + ML-KEM
• 기존 보안성과 양자 안전성을 함께 확보하기 위한 방법

서명 비교

ECDSA

• 서명이 약 72B
• 매우 작음

ML-DSA

• 약 3309B
• 크기가 매우 큼

→ 따라서 PQC를 적용하면 인증서와 패킷 크기가 증가함

실습

로컬 실습

mlkem_mldsa_demo.py

한 PC에서 코드 실행

확인 내용

• shared secret 생성 성공
• Verify 성공
• Verify 실패(변조)

crypto_size_speed_compare.py

이후 이 코드 실행 후 내용 비교

• 공개키 크기
• ciphertext 크기
• signature 크기
• 실행 시간

TCP 통신 실습

간단한 TLS와 비슷한 프로그램

**Client**

공개키 생성
공개키 전송

**Server**

Encapsulation 수행
ciphertext 생성
ML-DSA 서명 생성

**Client**

Verify 수행
shared secret 생성

AES-GCM으로 통신

→ 실제 TLS는 아니지만 구조는 매우 비슷

Wireshark 관찰

Wireshark에서는 tcp.port == 9001 필터를 사용함

관찰 가능한 값

• 공개키
• ciphertext
• signature
• nonce
• 암호문

관찰하면 안 되는 값

• shared secret
• AES Key
• 평문

👉 네트워크에선 무엇이 보여야 하고 무엇이 보이면 안 되는지를 확인하는 것이 핵심

TLS 1.3 연결

TLS 흐름

ClientHello

↓

ServerHello

↓

Shared Secret 생성

↓

Certificate 검증

↓

Finished

↓

Application Data

구현 시 주의할 취약점

• 디캡슐화 실패 처리
  • 실패 여부가 시간이나 오류 메시지로 노출되면 CCA 공격에 이용될 수 있음
• 상수시간(Constant-Time) 위반
  • 비밀값에 따라 실행 시간이 달라지면 타이밍 공격으로 정보가 유출될 수 있음
• 랜덤 품질 부족
  • 키 생성이나 nonce 생성에 사용하는 난수가 약하면 전체 보안이 무너질 수 있음
• 패킹/역패킹 버그
  • 비트 인코딩, 길이 검증, 엔디언 처리 등의 구현 실수로 취약점이 발생할 수 있음

하이브리드 전환과 PQC 도입

• PQC는 기존 알고리즘을 즉시 교체하는 것이 아니라 하이브리드 방식으로 점진적으로 전환하는 것이 권장됨

하이브리드 방식에서는 

X25519 shared secret
+
ML-KEM shared secret
↓
HKDF
↓
최종 세션키 생성

→ 두 알고리즘의 공유 비밀을 함께 사용하여 한쪽 알고리즘에 문제가 생겨도 전체 보안을 유지하도록 함

• PQC를 도입하기 위해서는 먼저 암호 사용 현황을 파악하고(TLS, SSH, VPN, 저장 데이터, 서명 등)
• 장기간 보호가 필요한 데이터를 우선 선정한 뒤, 테스트 환경(Pilot)과 하이브리드 운영을 거쳐 점진적으로 전환하는 로드맵을 제시

---

3회차 세미나도 끝났습니다.....

이전 내용보다는 비교적 이해할 수 있는 범위였던것 같습니다...!!

그래도 어렵긴 하지만요 ㅠㅠ

 

-다음에 계속...-