양자내성암호 동향의 핵심은 NIST가 2024년 8월 13일 FIPS 203·204·205를 최종 승인한 뒤, PC와 스마트폰의 TLS 연결이 하이브리드 키교환으로 바뀌기 시작했다는 점입니다. Chrome, Firefox, Apple, Windows가 이미 브라우저와 OS 업데이트에 반영하고 있어 일반 사용자는 보안 패치와 TLS 인증서 항목에서 변화를 확인하면 됩니다.
지금 단계는 RSA만 당장 폐기하는 전환이 아니라 기존 타원곡선과 포스트퀀텀 암호화를 함께 쓰는 하이브리드 구간입니다. 기기 설정에서 알고리즘 이름을 몰라도 최신 보안 업데이트와 TLS 핸드셰이크가 유지되는지만 보면 됩니다. 아래에서는 표준 이름과 브라우저·OS 버전, 인증서에서 볼 항목을 순서대로 적습니다.
양자내성암호가 지금 주목받는 이유
양자컴퓨터가 실용 규모로 커지면 지금 널리 쓰는 RSA와 타원곡선 키교환이 풀릴 수 있다는 위험이 이미 표준 일정에 올라 있습니다. 그래서 각국 표준 기관과 OS 제조사는 양자내성암호를 실험이 아니라 제품 기본값으로 옮기고 있습니다. 공개키 길이를 키우는 임시 처방만으로는 일정을 맞추기 어렵다고 보고 알고리즘 자체를 교체하는 쪽으로 모였습니다.
일반 PC와 스마트폰에서는 사이트 접속 TLS가 먼저 바뀌고 앱 업데이트만 받아도 핸드셰이크 조합이 바뀝니다. 지금 주목하는 이유는 해커 도구가 갑자기 등장해서가 아니라 데스크톱 브라우저와 모바일 OS가 이미 기본 배포를 시작했기 때문입니다. 백업 테이프에 쌓인 암호문을 나중에 푸는 시나리오까지 표준 문서가 염두에 두므로 제품 일정은 앞으로 당겨져 있습니다.
표준·제품에 반영되는 최신 기술 동향
(출처: Standards TTA)
제품 반영의 기준점은 2024년 8월 13일 NIST가 FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA를 최종 승인한 사건입니다. 키캡슐화와 전자서명이 문서 번호로 고정되면서 브라우저, OS, 인증서 소프트웨어가 같은 이름을 쓰기 시작했습니다.
사용자는 알고리즘 논문을 읽지 않아도 업데이트 로그에 ML-KEM이나 하이브리드 키교환이 보이는지로 표준 반영을 가늠하면 됩니다. 이 시점 이후 제품 일정은 파일럿이 아니라 기본 탑재 쪽으로 맞춰지고 있습니다. 서버와 클라이언트가 동시에 준비돼야 연결이 열리므로 한쪽만 올라간 버전에서는 기존 타원곡선으로 내려앉기도 합니다. 그래서 동향을 볼 때는 표준 문서 날짜와 실제 브라우저 기본값 날짜를 같이 적는 편이 정확합니다.
주요 알고리즘과 표준화 진행 상황
FIPS 203의 ML-KEM은 CRYSTALS-Kyber 기반 키캡슐화이며 파라미터는 ML-KEM-512, ML-KEM-768, ML-KEM-1024입니다. 난이도 가정은 Module-LWE이며 TLS 키교환에 쓰일 때 768이 기본 후보로 자주 등장합니다. ML-DSA는 격자 기반 서명이며 SLH-DSA는 해시 기반으로 성격이 다릅니다.
FIPS 204 ML-DSA와 FIPS 205 SLH-DSA는 서명용이며 Windows 인증서 서비스처럼 발급 쪽에 먼저 붙는 경우가 있습니다. 이름을 외울 필요는 없고 세 표준이 키교환과 서명을 나눠 맡는지만 보면 됩니다. 실험실 후보 이름이 아니라 FIPS 번호가 붙었기 때문에 펌웨어와 보안 라이브러리 배포 주기가 맞춰지기 쉬워졌습니다.
| 표준 | 알고리즘 | 역할 | 단말에서 보는 지점 |
|---|---|---|---|
| FIPS 203 | ML-KEM | 키캡슐화 | TLS 하이브리드 키교환 |
| FIPS 204 | ML-DSA | 전자서명 | AD CS 인증서 발급 |
| FIPS 205 | SLH-DSA | 전자서명 | SymCrypt·CNG API |
브라우저·OS·앱에 들어가는 방식
Chrome은 데스크톱에서 TLS 1.3과 QUIC용으로 Chrome 124부터 X25519Kyber768를 기본 활성화했고 이후 표준명 X25519MLKEM768 하이브리드로 전환했습니다. Firefox는 데스크톱 132부터 X25519MLKEM768를 기본 사용하고 QUIC와 HTTP/3는 135 이상에서 지원합니다.
Apple은 iOS·iPadOS·macOS 26부터 URLSession TLS에 양자내성 암호화를 기본으로 켜고 CryptoKit에 ML-KEM·ML-DSA를 넣었습니다. Windows는 SymCrypt와 CNG로 ML-KEM, ML-DSA, SLH-DSA를 제공하고 TLS 하이브리드와 Windows Server 2025 AD CS의 ML-DSA 발급을 반영 중입니다.
일반 IT 기기에서 체감되는 보안 변화
체감 지점은 설정 화면의 새 토글이 아니라 HTTPS 접속이 끊기지 않은 채 키교환 조합만 바뀌는 형태입니다. 데스크톱 Chrome과 Firefox는 이미 하이브리드 키합의를 기본값으로 두고 Apple 기기에서는 시스템 버전이 26대여야 URLSession 경로가 따라갑니다. Windows PC는 SymCrypt 계층이 먼저 준비되고 앱이 CNG를 호출해야 TLS 핸드셰이크에 반영됩니다.
따라서 체감은 속도 숫자보다 최신 브라우저·OS를 유지하는지에 가깝습니다. 게임 실행 속도가 갑자기 달라지는 식의 체감은 드물고 접속 로그의 키교환 이름만 바뀌는 경우가 많습니다. 구버전 앱이 자체 TLS 스택을 쓰면 OS가 준비돼도 하이브리드가 빠질 수 있으니 스토어 앱 업데이트도 같이 봐야 합니다.
업데이트·인증서에서 확인할 포인트
확인은 보안 업데이트 채널과 TLS 인증서 항목 두 갈래로 나누면 됩니다. 브라우저 버전은 Chrome 124 이후, Firefox는 데스크톱 132 이상, HTTP/3까지 보려면 135 이상을 보면 됩니다. 회사 PC는 그룹 정책으로 브라우저 채널이 묶여 있을 수 있어 개인 노트북보다 반영이 늦을 수 있습니다.
Apple은 시스템 소프트웨어 26과 CryptoKit 반영 여부를 확인하고 Windows는 AD CS가 ML-DSA 인증서를 발급할 수 있는 서버 구성인지를 봅니다. 인증서 화면에서 서명 알고리즘 이름이 ML-DSA로 바뀌었는지 사이트 인증서 체인 오류가 없는지만 점검하면 됩니다. 인증서를 갈아끼울 때는 중간 CA가 새 서명을 지원하는지부터 확인하지 않으면 체인 경고가 납니다.
양자내성암호 동향 정리
정리하면 지금 시점에서 양자내성암호는 2024년 8월 NIST FIPS 확정 이후 브라우저와 OS의 기본 TLS로 내려오고 있습니다. PC와 스마트폰 사용자는 알고리즘을 직접 고르지 않아도 Chrome·Firefox·Apple·Windows 업데이트를 따라가면 하이브리드 키교환에 들어갑니다. 당분간 RSA 폐기가 아니라 병행이 기본이며 인증서 서명 이름과 핸드셰이크 실패 여부만 보면 됩니다.
다음 점검은 기기 OS 버전과 브라우저 빌드가 위에 적은 수치를 넘겼는지입니다. 체크 순서는 OS 빌드 번호, 브라우저 버전, 사이트와 사내 TLS 인증서의 서명 이름입니다. 세 값이 맞으면 양자내성암호 동향은 이미 기기 안에 들어와 있는 상태로 보면 됩니다. 업데이트 채널이 지연되면 표준은 확정돼도 단말은 예전 키교환을 씁니다.
