(포스트양자) 암호화의 정답

AI 요약

Filippo Valsorda가 개발자를 위한 암호화 권고안을 새로 정리했습니다. Colin Percival의 2009년 글 이후 여러 차례 이어진 안내서의 최신판입니다. 글은 포스트양자 전환 일정이 2026년 초 크게 앞당겨졌으며 2029년까지 전환해야 한다는 합의가 형성됐다고 설명합니다. Grover 알고리즘은 대칭키 암호에 실질적인 위협이 아니므로 대칭 암호 권고는 대체로 유지되지만, 비대칭 암호 선택은 2024년판과 비교해도 크게 달라졌습니다. 규제 요구가 따로 없다면 대부분 FIPS 140과 호환되는 선택을 제시합니다.

대칭 암호와 해시

클라우드에서는 KMS를 우선 사용하고, 로컬 데이터는 XAES-256-GCM이나 XChaCha20Poly1305와 128비트 이상의 무작위 논스를 권합니다. 일반 AES-GCM이나 ChaCha20Poly1305에 무작위 논스를 쓸 때는 키 하나로 암호화하는 메시지가 10억 개를 넘지 않는다는 확신이 필요합니다. 수 MB가 넘는 데이터는 한 번의 AEAD 연산에 넣지 말고, 메시지를 나눠 인증하는 STREAM 방식을 사용해야 합니다. 글은 TLS에서 파생한 Cobblestone-128을 추천하며 pyca/cryptography에서 사용할 수 있고 Go 표준 라이브러리에도 들어올 예정이라고 설명합니다.

대칭키 길이는 특별히 고민할 필요가 없으며, 하나를 골라야 한다면 256비트를 권합니다. 다만 Cobblestone처럼 다중 표적 공격을 분석한 암호군이 128비트 키를 쓰는 경우까지 바꿀 필요는 없습니다. 메시지 인증에는 HMAC-SHA-256을 권하고, 파싱이나 정규화 차이로 생기는 오류를 피하려면 재계산한 데이터가 아니라 원본 바이트열에 인증 코드를 붙이라고 합니다. 해시는 SHA-2로 충분하며, 여러 값을 함께 해시해야 한다면 직접 조합하지 말고 SequenceHash나 TupleHash를 사용하라고 권합니다.

비밀번호와 난수

무작위 ID에는 운영체제 CSPRNG가 만든 32바이트 난수를 권합니다. UUIDv4처럼 약 128비트인 값도 대개 충분하지만, 고유 값이 2⁴⁸개를 넘는 상황에서는 더 긴 값을 고려해야 합니다. 비밀번호 해싱은 Argon2id 또는 scrypt를 권합니다. Argon2id는 메모리 64MiB, 반복 횟수 2, 병렬도 1을 제안하고, scrypt는 N=2¹⁶, r=8, p=1을 제시합니다. 로그인 용도라면 비밀번호 해싱을 세밀하게 조정하기보다 피싱 방지 패스키를 도입할 수 있는지 먼저 검토하라고 덧붙입니다. 패스키는 아직 포스트양자 방식은 아니지만 피싱과 자격 증명 대입 공격을 막는다는 설명입니다.

포스트양자 키 교환과 공개키 암호

키 교환은 표준 프로토콜에서 X25519와 ML-KEM-768을 결합한 방식을 권합니다. TLS에서는 X25519MLKEM768, SSH에서는 mlkem768x25519-sha256, HPKE와 age에서는 MLKEM768-X25519를 예로 듭니다. 고전 공개키만 쓰면 공격자가 암호문을 저장했다가 나중에 복호화하는 harvest-now-decrypt-later 공격에 노출됩니다. 하이브리드 방식을 구현하느라 전환이 한 달이라도 늦어질 상황이면 순수 ML-KEM-768을 바로 쓰는 편이 낫다고 합니다.

비대칭 암호화에는 HPKE 조합 MLKEM768-X25519(X-Wing), HKDF-SHA256, AES-128-GCM을 권합니다. 여러 수신자나 명령행 도구가 필요하면 포스트양자 키를 지원하는 age를 선택할 수 있습니다. 큰 메시지는 한 번의 암호화 호출에 넣지 말고 Cobblestone 방식처럼 나눠 처리하라고 합니다. 비대칭 서명은 ML-DSA-44를 권하며, 메시지를 먼저 해시해야 한다면 HashML-DSA 대신 external-μ 서명을 사용하고 키는 32바이트 시드로 저장하라고 설명합니다. 서명이 꼭 필요한지 먼저 따져 HMAC이나 무작위 세션 토큰으로 대체할 수 있는지 살펴보라는 조언도 담았습니다.

TLS와 백업

클라우드에서는 ALB/NLB를 사용하고, 직접 TLS를 구성한다면 rustls, Go의 crypto/tls, BoringSSL, AWS-LC, s2n-tls 등을 권합니다. 선택한 구현이 TLS 1.3과 X25519MLKEM768 키 교환을 우선하는지 확인해야 합니다. 웹사이트에는 널리 쓰이고 관리가 활발한 ACME 클라이언트를 권하며, 직접 ACME 클라이언트를 만들지 말라고 합니다. 온라인 백업에는 긴 무작위 비밀번호를 쓰는 restic을 추천합니다. Tarsnap은 오랫동안 좋은 선택이었지만 RSA 기반 비대칭 암호를 사용하므로 포스트양자 전환을 고려하면 주의가 필요하다고 설명합니다.

Lobsters 반응

• @olliej — 양자 컴퓨팅이 대칭 암호에는 사실상 영향을 주지 않는다는 점을 바로 짚어줘서 좋습니다.
• @robalex — SequenceHash를 발견해서 기쁩니다. 튜플 해싱 방식의 버그를 본 적은 있지만, 정식 해법이 있는 줄 몰랐습니다. 이 시리즈에서는 늘 뭔가를 배웁니다.
  • @fanf — 최근 SequenceHash에 관한 글이 하나 올라왔습니다.

원문: Filippo Valsorda / 번역·요약: Trawling