AES-GCM에서 같은 키로 nonce를 재사용하면 왜 위험한가요?

AES-GCM 같은 AEAD에서는 고정된 키에서 각 암호화 호출의 nonce가 다시 나오지 않는다는 계약이 핵심입니다. nonce는 비밀일 필요가 없고 ciphertext와 함께 저장할 수 있지만 같은 key + nonce 조합 재사용은 보안 분석의 전제를 깹니다. 그 결과 기밀성뿐 아니라 인증 태그의 안전성도 손상될 수 있으므로 암호문이 다르면 괜찮다고 할 수 없습니다.

대표적인 사고는 재시작입니다. K7과 counter nonce를 쓰던 프로세스가 crash 뒤 0부터 다시 쓰면 같은 조합이 생깁니다. 복제 인스턴스가 같은 K7로 각자 1부터 세는 경우도 같습니다. 비휘발성 checkpoint, writer별 고유 prefix, key 세대 분리 중 하나로 유일성을 보장합니다. RFC 5116은 장기 key와 여러 장치에서 이런 조정이 필요하다고 설명합니다.

무작위 nonce도 충돌 가능성이 0은 아닙니다. 실제 nonce 길이·호출 한도·랜덤 생성기와 복구 정책을 GCM profile에서 확인해야 합니다. 유일성을 증명하기 어렵다면 key를 오래 공유하지 않고 새 세대로 범위를 줄이는 설계를 검토합니다. 재사용이 의심되면 nonce를 숨기거나 다시 wrap하는 것으로 해결하지 않고 영향 범위와 re-encryption을 평가합니다.

nonce 상태를 DB 거래와 함께 다루는 경우에도 예약과 실제 seal의 경계를 명확히 해야 합니다. 번호를 예약한 뒤 프로세스가 죽으면 그 번호를 버리는 것은 괜찮지만, 예약을 롤백해 다른 worker가 다시 쓰게 하면 안 됩니다. 백업을 복원할 때 counter 상태만 되돌아가는 문제도 있으므로 key 세대나 복원 epoch를 nonce prefix에 포함하는 방식을 검토합니다. 이미 같은 key와 nonce가 사용됐다는 증거가 있으면 영향을 받은 데이터의 신뢰성을 다시 평가해야 하며, 단순한 metadata 수정으로 기존 태그의 보안 전제가 복구되지는 않습니다.

예약 상태도 사고 원인을 가릅니다. worker가 nonce 17을 영구 저장소에 예약한 뒤 seal 전에 죽었다면 17을 버리고 18부터 진행하는 것은 안전하지만, 실제로 seal에 쓰였는지 불확정인 번호 17을 rollback으로 재할당하면 재사용 위험이 생깁니다. seal 전에 종료됐다는 사실을 확실히 아는 경우와 구분하되 운영 프로토콜은 보수적으로 예약 번호를 재사용하지 않습니다. 반대로 단순히 counter가 사라졌다는 의심만으로 이미 생성된 모든 암호문이 재사용됐다고 결론내리지는 말고, key 세대·writer ID·복구 시각의 로그를 대조해 확인된 범위를 격리합니다. 재사용이 확인되면 새 key 발급은 이후 호출을 막는 조치일 뿐이고, 영향을 받은 ciphertext의 기밀성과 무결성 판단 및 필요 시 재암호화를 별도로 결정합니다.