nonce는 암호 알고리즘의 입력에 쓰이는 값으로, 이름 자체가 비밀을 뜻하지 않습니다. 다만 공개해도 되는지, 같은 키 아래 다시 써도 되는지, 어떤 방식으로 만들어야 하는지는 알고리즘과 모드의 명세를 따라야 합니다.
RFC 8446은 각 방향의 64비트 기록 순번을 0부터 증가시키고, 순번을 정해진 길이로 채운 뒤 방향별 고정 IV와 XOR해 기록 nonce를 만듭니다. 이 구체 규칙을 모든 암호의 규칙으로 일반화해서는 안 됩니다.
nonce가 비밀키와 같은 말은 아닙니다
nonce는 한 번의 암호 연산이나 메시지에서 함께 쓰는 값입니다. 이름을 풀면 ‘number used once’라는 설명을 자주 만나지만, 이 기억법만으로 모든 표준의 보안 조건을 알 수는 없습니다. nonce는 비밀키가 아니며, 특정 구성에서는 공개되어도 됩니다. 그렇다고 모든 nonce를 어느 상황에서나 공개해도 안전하다는 뜻도 아닙니다. 알고리즘은 nonce가 비밀인지 아닌지, 반복을 허용하는지, 예측 가능해도 되는지에 관한 조건을 각각 정할 수 있습니다.
| 속성 | 확인할 질문 | 실수하기 쉬운 해석 |
|---|---|---|
| 비밀성 | 공격자가 값을 알아도 되는가? | 키와 같은 비밀이라고 단정 |
| 고유성 | 같은 키 아래 값이 반복될 수 있는가? | 모든 방식에서 반복 금지 또는 허용이라고 일반화 |
| 무작위성 | 값을 예측하기 어렵게 생성해야 하는가? | nonce는 언제나 난수여야 한다고 생각 |
고유성은 충돌 없이 서로 다른 값을 쓰라는 조건이고, 무작위성은 생성 과정의 확률적 성질입니다. 카운터는 올바르게 관리하면 무작위가 아니어도 서로 다른 값을 만들 수 있습니다. 반대로 난수 생성도 상태 관리가 잘못되면 값이 반복될 수 있습니다. 어느 속성이 필요한지는 알고리즘 명세로 확인해야 합니다. 이 글은 RFC 8446의 TLS 기록 보호만 다룹니다.
TLS 기록 순번이 nonce 구성에 쓰이는 방식
RFC 8446 §5.3은 읽기와 쓰기 각각에 별도의 64비트 순번을 둡니다. 연결이 시작되거나 키가 바뀌면 해당 순번은 0으로 설정되고, 그 키로 보내는 첫 기록은 0을 씁니다. 기록을 하나 처리할 때마다 해당 방향의 값이 하나 증가합니다. 순번이 돌아가야 하는 상황에서는 순환시키지 말고 재키잉하거나 연결을 끝내야 한다고 규정합니다. 따라서 이 문서의 모델에서 같은 방향·같은 트래픽 키 아래 순번을 실수로 반복시키지 않는 것이 핵심입니다.
- 송신 방향의 새 트래픽 키를 설정하고 순번을 0으로 둡니다.
- 첫 기록에는 0, 다음 기록에는 1, 세 번째 기록에는 2를 배정합니다.
- 64비트 순번을 네트워크 바이트 순서로 표현하고 필요한 길이까지 왼쪽을 0으로 채웁니다.
- 채운 순번과 해당 방향의 static write IV를 XOR한 결과를 기록 nonce로 사용합니다.
- 키를 바꾸면 새 키의 순번 공간을 0부터 다시 시작합니다. 이 초기화는 키가 그대로인 채 순번을 재사용해도 된다는 뜻이 아닙니다.
교육용으로 실제 연결 값이 아닌 12바이트 IV a0 00 00 00 00 00 00 00 00 00 00 00을 둡니다. 순번 0을 12바이트로 채우면 모두 0이므로 XOR 결과는 IV와 같습니다. 순번 1은 00 00 00 00 00 00 00 00 00 00 00 01이고, XOR 결과는 a0 00 00 00 00 00 00 00 00 00 00 01입니다. 순번 2의 XOR 결과는 a0 00 00 00 00 00 00 00 00 00 00 02입니다. 이 가상 계산은 실제 키나 nonce를 보여 주지 않습니다.
카운터 사용을 모든 알고리즘으로 넓히지 않습니다
RFC 8446의 예만 보고 nonce는 무작위일 필요가 없다고 모든 알고리즘에 적용하면 틀릴 수 있습니다. 이 프로토콜은 지원하는 AEAD 범위와 IV 구성 절차를 함께 정의합니다. 다른 알고리즘이나 모드는 전역 유일성, 난수 생성, 메시지 번호 조합 등 다른 조건을 정할 수 있습니다. 읽기 순번과 쓰기 순번도 각각 관리하므로 한쪽 값을 다른 방향에 복사하지 않습니다. 답을 쓸 때는 알고리즘·모드·키 범위를 함께 적습니다.
NIST SP 800-57 Part 1 Rev. 5는 암호 키 재료를 어떻게 보호하고 관리할지 안내하는 일반 문서입니다. 키 교체와 보호가 중요한 이유를 이해하는 데에는 참고가 되지만, RFC 8446 §5.3의 nonce 조합식을 대신 정의하지는 않습니다. 서로 다른 두 문서를 인용할 때는 하나가 키 관리 맥락을 제공하고 다른 하나가 해당 프로토콜의 정확한 계산 규칙을 제공한다는 역할을 구분해야 합니다.
회상 연습: 새 키와 새 nonce 조건을 구별합니다
교육용 문제입니다. RFC 8446의 송신 방향에서 같은 트래픽 키로 첫 번째 기록과 두 번째 기록을 보냅니다. 각각의 순번은 무엇인가요? 이어서 키가 변경되면 다음 키의 첫 기록은 어떤 순번을 사용하나요? 마지막으로, 이 사례만으로 모든 암호 알고리즘에서 nonce가 카운터여도 된다고 결론 내릴 수 있나요?
답은 0, 1, 그리고 키 변경 후 새 키에 대한 0입니다. RFC 8446은 키 변경 때 순번을 재설정합니다. 이 결론은 해당 프로토콜 규칙에 한정됩니다. 다른 알고리즘은 자체 명세에서 nonce 생성 방법과 재사용 조건을 확인해야 합니다. ‘비밀인가’뿐 아니라 고유성·무작위성·키 범위를 따로 점검합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
RFC 8446의 송신 방향에서 같은 트래픽 키로 세 기록을 보낼 때 순번은 무엇이며, 키가 바뀐 뒤 첫 기록의 순번은 무엇인가?
정답과 해설 확인
기존 키의 세 기록은 0, 1, 2이고 키가 바뀐 뒤 새 키의 첫 기록은 0입니다.RFC 8446 §5.3은 연결 시작과 키 변경 때 방향별 순번을 0으로 두고 기록마다 증가시킵니다. 이 규칙은 TLS 기록 보호에 한정되며 모든 암호의 nonce 정책으로 일반화하지 않습니다.