페이지 하단에 중요한 내용이 숨어 있음. OpenSSH에 적용된 모든 포스트퀀텀 알고리즘은 "하이브리드" 방식으로, 포스트퀀텀 키 교환 방식(예: ML-KEM)과 기존 방식(x25519)을 동시에 사용함. 두 가지 알고리즘을 함께 사용함으로써, 혹시 향후 포스트퀀텀 알고리즘이 완전히 깨지더라도 최소한 기존만큼의 보안성은 지킬 수 있음. 하이브리드 덕분에 기존 대비 보안 손실이 없다는 점이 핵심임
하이브리드 방식은 한 쪽 알고리즘이 뚫려도 나머지 쪽을 통해 복원력을 제공하는 장점이 있음. 하지만 반대로 구현 버그, 사이드 채널 취약점 노출도는 두 배 이상이 됨. 실제로는 양자컴퓨터 위협이 현실이 아니지만, 그러한 버그와 취약점은 당장 현실의 이슈임. 다만, 최근 10년간 엄청난 보안 연구와 검증이 진행되어, 이런 트레이드오프도 충분히 감내할 만하다고 판단함
산업계 전체가 대부분 하이브리드 PQC-클래식 구조로 움직이고 있음. 진짜로 기존 RSA, ECC, DH가 뚫릴 수준의 양자컴퓨터가 나타나기 전까지는, 두 종류의 자물쇠를 병렬로 거는 보수적인 방법이 현재로선 가장 안전한 선택 같음. 한편, NSA의 CNSA 2.0 알고리즘(링크)은 오직 포스트퀀텀 계열만을 채택하고, 하이브리드 방식은 굳이 필요 없다고 공식 FAQ에서 밝힘
최근 발표된 편파적이고 재미있는 논문(링크)을 감안할 때, 현재 속도의 포스트퀀텀 크립토 도입이 정말 필요한지 궁금해짐. 내가 알기론 포스트퀀텀 키 자료는 기존 대비 엄청나게 커서 네트워크 트래픽, CPU 소모도 크게 증가함
이 글은 SSH 연결에서 키 교환에만 PQC를 적용하는 얘기라, 오버헤드는 상당히 미미한 수준임. 그리고 FAQ에도 나와있듯, "양자컴퓨터가 아직 없는데 왜 미리 준비해야 하느냐"는 질문에 대해, 오늘 송신하는 트래픽이 나중에 해독될 위험(“store now, decrypt later” 공격) 때문임. 양자컴퓨터가 실현 불가능함을 주장하는 사람도 있지만, 주요 장애물은 물리 법칙이 아니라 엔지니어링 문제임. 만약 양자컴퓨터가 정말 실현된다면 엄청난 양의 사용자 데이터를 지켜낼 수 있는 것임. 논문도 재미로 한 번 읽는 건 추천하지만, 지나치게 냉소적으로 받아들이지는 않음
그 논문이 웃기긴 하지만, 조롱만 할 만한 건 아님. 실제로 의미 있는 진전도 이루어지고 있음. PQCrypto 2025에서 Sam Jacques의 발표(링크)를 추천함. 지난 10년 동안, 양자 컴퓨터 기반 소인수분해 비용이 1000배 감소했고, 하드웨어 쪽 오류율도 엄청 줄었음(링크1, 링크2, 링크3, 링크4). 양자컴퓨터 발전을 관찰하고 싶으면, 점진적인 내구성 향상을 추적하면 됨. 노이즈가 큰 장애물이고, 일단 품질 문제가 양쪽에서 해결되면 본격적인 발전이 기대됨
그 논문은 농담이라고 생각될 정도임. 만약 진지한 비판이라면, 1951년에 트랜지스터가 파이를 계산 못 한다고 불평하는 것과 비슷함. PQC 도입의 필요성은 다음 두 가지 질문에 달려 있음: 1) 내 평생 양자컴퓨터가 등장하지 않을 거라고 믿는지, 2) 내가 맡긴 데이터의 민감성 가치를 얼마나 두는지. 만약 두 가지 모두에 별 관심이 없다면 PQC는 시간 낭비일 수 있음. 하지만 내가 암호 시스템을 유지하는 입장이라면, 사용자 데이터의 가치를 무시할 권한은 없다고 생각함
현재 진행 중인 논의 대부분은 키 교환과 관련됨. 키 교환은 드물게 이뤄지고, 오버헤드는 대체로 부담이 없음. 주요 사항을 정리하자면: 1) PQ 알고리즘(서명, 키 교환)은 키 사이즈가 훨씬 크지만 연산 속도는 오히려 빠르거나 비슷함. 2) TLS, SSH 같은 대부분 프로토콜은 초기 연결 때만 키 교환이 이뤄지므로 키 사이즈가 큰 건 그리 문제되지 않음. 단, TCP MTU 초과 등 호환성 이슈는 있을 수 있음. Signal, MLS처럼 매우 자주 키 교환하는 프로토콜에서는 가끔만 PQ로 리키 함(참고). 3) TLS의 경우, 서명 메시지 사이즈가 더 큰 문제가 됨. 인증서 체인에 서명이 많기 때문임. 그래서 PQ 서명의 TLS 도입 viability에 더 큰 고민이 있음(참고)
공개 정보 외에도, 우리 정보기관이 20년 이상 기밀 유지가 필요한 시스템에 PQ 도입을 권고한다는 점은 신뢰 요인임. 자료를 공유하자면: 2014년 네덜란드 정보기관은 2030~2040년, 2021년에는 2030년까지 등장 가능성은 낮지만 무시 못 한다고 언급함. 2025년에는 18개국이 공동 논평에서 2030년까지 'store now, decrypt later' 공격에 대비하라고 발표했음(문서1, 문서2, 공동성명)
Secretive라는 macOS 앱은 Secure Enclave에 SSH key를 저장함. 지원 알고리즘 때문에 ecdsa-sha2-nistp256을 사용 중인데, Secure Enclave에서 PQ 알고리즘은 아마 지원하지 않는 듯함. 혹시 mlkem768×ecdsa-sha2-nistp256처럼 하이브리드로 묶어서, ECDSA 부분만 SE에서 처리하는 게 가능할지 궁금함(Secretive GitHub)
여기서의 공지는 키 교환(aka KEX aka Key Exchange)에 관한 것이고, SSH 자기 키 그 자체와는 무관함. SSH 옵션 중 ecdsa-sha2-nistp256은 KexAlgorithms에서 허용되지 않고, ecdh-sha2-nistp256이 그 대안임. 참고1, 참고2
ssh-audit(링크) 도구가 이론적 알고리즘(PQC 하이브리드)을 확인하는 항목을 추가해야 한다고 생각함. 특정 알고리즘만 고정해서 써도 여전히 "A" 등급이 뜨는 것 같음. 현재 cha-cha만 쓰는 중임
FIPS 140-3 준수 OpenSSH용 PQC 하이브리드 알고리즘이 있는지가 궁금함
FIPS 인증은 전체 "암호화 모듈(하드/소프트웨어 포함)"에 내려짐. 그래서 "FIPS 인증된 OpenSSH"라는 말은 사실상 잘못된 표현임. 특정 OS, 하드웨어에 OpenSSH를 태운 상태로 인증받아야 함. FIPS는 특정 알고리즘 사용이 필수이고, ML-KEM은 NIST 승인임. 내 이해로는 NIST에서도 하이브리드 KEM을 인정한다고 알고 있음. 따라서 OpenSSH 지원 알고리즘인 mlkem768x25519-sha256도 인증 받을 수 있다고 생각함. 단, 나는 FIPS 감사관은 아님
미리 대비하려는 접근은 합리적임. 키 변경이 비교적 사소한 작업일 때 더욱 그렇다 생각함. 두 옵션 중 어떤 것이 더 강력한지, 아마 512가 더 강한 것 아닌지 궁금함
두 알고리즘은 완전히 다름. mlkem768x25519-sha256은 ML-KEM PQ 키 교환과 기존 ECDH/x25519를 섞은 하이브리드임. 이렇게 하면 둘 중 하나가 깨져도 기존 수준은 지킬 수 있음. 그리고 256버전(mlkem768)은 실제로 512버전(sntrup761)보다 나중에 나왔고, OpenSSH 9.0부터 sntrup761x25519-sha512 지원, 9.9부터 mlkem768x25519-sha256 지원임
256비트, 512비트 크기 문제는 지금 당장 걱정할 필요가 전혀 없음. 128비트 공간 조차도 샅샅이 탐색할 전력 조차 없고, 그런 컴퓨터도 없음. 걱정할 타이밍이 아님
mlkem이 현시점에서는 합리적인 디폴트임. 업계 표준이 이쪽으로 모이고 있음
내가 터미널 기반 마이크로블로깅/채팅 앱을 만들어서 이쪽(포스트퀀텀 보안)으로 전환할까 고민함. Paul Durov 인터뷰를 여러 번 보고, 그가 겪은 일을 들으면서 더욱 고민해 봄
그가 겪은 일이 구체적으로 뭔지 궁금하고, 블로그는 왜 ssh가 필요한지 궁금함
sntrup761x25519-sha512와 mlkem768x25519-sha256 둘 중 뭐가 나은지 궁금함
MLKEM768은 더 나은 성능과 더 작은 키를 제공함. SNTRUP761은 보안 가정이 더 강하고, 잠재적 크립토 분석 공격에 대한 내구성이 더 뛰어남
NTRU Prime(sntrup)는 역사적 이유로 들어간 것임(mlkem이 당시에는 없었음). 둘 중 아무거나 써도 무방하지만, sntrup는 예전 GPG가 CAST를 기본으로 썼던 것처럼 한때의 기본값 느낌임
언제 PQ 인증서(호스트/사용자 인증용 키)도 제공될지 궁금함
이 내용은 해당 페이지에 언급되어 있음
선제적으로 이런 시도에 나서는 건 좋은 일임. 미래에 더 나은 보안을 갖춘 대안이 나와도, 현재 상황보다 더 나빠지지 않는 한, 이런 노력이 의미 없음은 아니라 생각함
내가 100% 장악하지 못하는 네트워크를 통해 서버에 접속한다면, 트래픽은 어딘가에 저장될 것임을 전제해야 함. 결국 포스트퀀텀 시대가 오면 그 트래픽이 복호화될 수도 있음. 그게 실제로 걱정해야 할만한 문제인지는 사용자 상황에 따라 다름
Hacker News 의견
페이지 하단에 중요한 내용이 숨어 있음. OpenSSH에 적용된 모든 포스트퀀텀 알고리즘은 "하이브리드" 방식으로, 포스트퀀텀 키 교환 방식(예: ML-KEM)과 기존 방식(x25519)을 동시에 사용함. 두 가지 알고리즘을 함께 사용함으로써, 혹시 향후 포스트퀀텀 알고리즘이 완전히 깨지더라도 최소한 기존만큼의 보안성은 지킬 수 있음. 하이브리드 덕분에 기존 대비 보안 손실이 없다는 점이 핵심임
하이브리드 방식은 한 쪽 알고리즘이 뚫려도 나머지 쪽을 통해 복원력을 제공하는 장점이 있음. 하지만 반대로 구현 버그, 사이드 채널 취약점 노출도는 두 배 이상이 됨. 실제로는 양자컴퓨터 위협이 현실이 아니지만, 그러한 버그와 취약점은 당장 현실의 이슈임. 다만, 최근 10년간 엄청난 보안 연구와 검증이 진행되어, 이런 트레이드오프도 충분히 감내할 만하다고 판단함
산업계 전체가 대부분 하이브리드 PQC-클래식 구조로 움직이고 있음. 진짜로 기존 RSA, ECC, DH가 뚫릴 수준의 양자컴퓨터가 나타나기 전까지는, 두 종류의 자물쇠를 병렬로 거는 보수적인 방법이 현재로선 가장 안전한 선택 같음. 한편, NSA의 CNSA 2.0 알고리즘(링크)은 오직 포스트퀀텀 계열만을 채택하고, 하이브리드 방식은 굳이 필요 없다고 공식 FAQ에서 밝힘
최근 발표된 편파적이고 재미있는 논문(링크)을 감안할 때, 현재 속도의 포스트퀀텀 크립토 도입이 정말 필요한지 궁금해짐. 내가 알기론 포스트퀀텀 키 자료는 기존 대비 엄청나게 커서 네트워크 트래픽, CPU 소모도 크게 증가함
이 글은 SSH 연결에서 키 교환에만 PQC를 적용하는 얘기라, 오버헤드는 상당히 미미한 수준임. 그리고 FAQ에도 나와있듯, "양자컴퓨터가 아직 없는데 왜 미리 준비해야 하느냐"는 질문에 대해, 오늘 송신하는 트래픽이 나중에 해독될 위험(“store now, decrypt later” 공격) 때문임. 양자컴퓨터가 실현 불가능함을 주장하는 사람도 있지만, 주요 장애물은 물리 법칙이 아니라 엔지니어링 문제임. 만약 양자컴퓨터가 정말 실현된다면 엄청난 양의 사용자 데이터를 지켜낼 수 있는 것임. 논문도 재미로 한 번 읽는 건 추천하지만, 지나치게 냉소적으로 받아들이지는 않음
그 논문이 웃기긴 하지만, 조롱만 할 만한 건 아님. 실제로 의미 있는 진전도 이루어지고 있음. PQCrypto 2025에서 Sam Jacques의 발표(링크)를 추천함. 지난 10년 동안, 양자 컴퓨터 기반 소인수분해 비용이 1000배 감소했고, 하드웨어 쪽 오류율도 엄청 줄었음(링크1, 링크2, 링크3, 링크4). 양자컴퓨터 발전을 관찰하고 싶으면, 점진적인 내구성 향상을 추적하면 됨. 노이즈가 큰 장애물이고, 일단 품질 문제가 양쪽에서 해결되면 본격적인 발전이 기대됨
그 논문은 농담이라고 생각될 정도임. 만약 진지한 비판이라면, 1951년에 트랜지스터가 파이를 계산 못 한다고 불평하는 것과 비슷함. PQC 도입의 필요성은 다음 두 가지 질문에 달려 있음: 1) 내 평생 양자컴퓨터가 등장하지 않을 거라고 믿는지, 2) 내가 맡긴 데이터의 민감성 가치를 얼마나 두는지. 만약 두 가지 모두에 별 관심이 없다면 PQC는 시간 낭비일 수 있음. 하지만 내가 암호 시스템을 유지하는 입장이라면, 사용자 데이터의 가치를 무시할 권한은 없다고 생각함
현재 진행 중인 논의 대부분은 키 교환과 관련됨. 키 교환은 드물게 이뤄지고, 오버헤드는 대체로 부담이 없음. 주요 사항을 정리하자면: 1) PQ 알고리즘(서명, 키 교환)은 키 사이즈가 훨씬 크지만 연산 속도는 오히려 빠르거나 비슷함. 2) TLS, SSH 같은 대부분 프로토콜은 초기 연결 때만 키 교환이 이뤄지므로 키 사이즈가 큰 건 그리 문제되지 않음. 단, TCP MTU 초과 등 호환성 이슈는 있을 수 있음. Signal, MLS처럼 매우 자주 키 교환하는 프로토콜에서는 가끔만 PQ로 리키 함(참고). 3) TLS의 경우, 서명 메시지 사이즈가 더 큰 문제가 됨. 인증서 체인에 서명이 많기 때문임. 그래서 PQ 서명의 TLS 도입 viability에 더 큰 고민이 있음(참고)
공개 정보 외에도, 우리 정보기관이 20년 이상 기밀 유지가 필요한 시스템에 PQ 도입을 권고한다는 점은 신뢰 요인임. 자료를 공유하자면: 2014년 네덜란드 정보기관은 2030~2040년, 2021년에는 2030년까지 등장 가능성은 낮지만 무시 못 한다고 언급함. 2025년에는 18개국이 공동 논평에서 2030년까지 'store now, decrypt later' 공격에 대비하라고 발표했음(문서1, 문서2, 공동성명)
Secretive라는 macOS 앱은 Secure Enclave에 SSH key를 저장함. 지원 알고리즘 때문에 ecdsa-sha2-nistp256을 사용 중인데, Secure Enclave에서 PQ 알고리즘은 아마 지원하지 않는 듯함. 혹시 mlkem768×ecdsa-sha2-nistp256처럼 하이브리드로 묶어서, ECDSA 부분만 SE에서 처리하는 게 가능할지 궁금함(Secretive GitHub)
ssh-audit(링크) 도구가 이론적 알고리즘(PQC 하이브리드)을 확인하는 항목을 추가해야 한다고 생각함. 특정 알고리즘만 고정해서 써도 여전히 "A" 등급이 뜨는 것 같음. 현재 cha-cha만 쓰는 중임
FIPS 140-3 준수 OpenSSH용 PQC 하이브리드 알고리즘이 있는지가 궁금함
미리 대비하려는 접근은 합리적임. 키 변경이 비교적 사소한 작업일 때 더욱 그렇다 생각함. 두 옵션 중 어떤 것이 더 강력한지, 아마 512가 더 강한 것 아닌지 궁금함
두 알고리즘은 완전히 다름. mlkem768x25519-sha256은 ML-KEM PQ 키 교환과 기존 ECDH/x25519를 섞은 하이브리드임. 이렇게 하면 둘 중 하나가 깨져도 기존 수준은 지킬 수 있음. 그리고 256버전(mlkem768)은 실제로 512버전(sntrup761)보다 나중에 나왔고, OpenSSH 9.0부터 sntrup761x25519-sha512 지원, 9.9부터 mlkem768x25519-sha256 지원임
256비트, 512비트 크기 문제는 지금 당장 걱정할 필요가 전혀 없음. 128비트 공간 조차도 샅샅이 탐색할 전력 조차 없고, 그런 컴퓨터도 없음. 걱정할 타이밍이 아님
mlkem이 현시점에서는 합리적인 디폴트임. 업계 표준이 이쪽으로 모이고 있음
내가 터미널 기반 마이크로블로깅/채팅 앱을 만들어서 이쪽(포스트퀀텀 보안)으로 전환할까 고민함. Paul Durov 인터뷰를 여러 번 보고, 그가 겪은 일을 들으면서 더욱 고민해 봄
sntrup761x25519-sha512와 mlkem768x25519-sha256 둘 중 뭐가 나은지 궁금함
MLKEM768은 더 나은 성능과 더 작은 키를 제공함. SNTRUP761은 보안 가정이 더 강하고, 잠재적 크립토 분석 공격에 대한 내구성이 더 뛰어남
NTRU Prime(sntrup)는 역사적 이유로 들어간 것임(mlkem이 당시에는 없었음). 둘 중 아무거나 써도 무방하지만, sntrup는 예전 GPG가 CAST를 기본으로 썼던 것처럼 한때의 기본값 느낌임
언제 PQ 인증서(호스트/사용자 인증용 키)도 제공될지 궁금함
선제적으로 이런 시도에 나서는 건 좋은 일임. 미래에 더 나은 보안을 갖춘 대안이 나와도, 현재 상황보다 더 나빠지지 않는 한, 이런 노력이 의미 없음은 아니라 생각함