요약

  • RFC 10032는 IRTF 스트림의 Informational 문서로, CFRG 합의의 산물입니다. IETF Standards Track의 위임이 아니며, IANA에 등록된 여섯 개 코드는 안정적인 이름일 뿐 배포 의무가 아닙니다.
  • 이 코드들은 AEGIS-128L, AEGIS-256, 그리고 X2/X4 병렬 형태 네 가지를 구분하지만, 128비트 또는 256비트 태그 선택은 담고 있지 않습니다. 병렬 모드는 선택 사항이며 정확한 변형에 대한 합의가 필요합니다.
  • 라이브러리 자가 테스트는 고정 입력에 대한 결과만 보증합니다. 피어 간 제안과 선택, 실행된 바이너리와 CPU 경로, nonce 및 연관 데이터 구성, 실제 트래픽에서 관측된 스위트는 보증하지 않습니다.
  • 보관 영수증은 문서와 레지스트리, 프로토콜 프로필, 인증된 선택, 코드와 태그, 키 및 nonce 주기, 연관 데이터 직렬화, 실행 경로, 양성·음성 테스트, 실패 처리, 카운터, 폴백과 롤백을 연결해야 합니다.

레지스트리는 이름을 해결할 뿐 세션을 해결하지 않는다

IANA는 32를AEAD_AEGIS128L에, 33을AEAD_AEGIS256에, 34와 35를 AEGIS-128X2/X4에, 36과 37을 AEGIS-256X2/X4에 할당했습니다. 이는 서로 다른 사양이 호환되지 않는 알고리즘에 동일한 식별자를 주장하는 일을 막아줍니다. 또한 인터페이스, 구성 또는 인벤토리가 한 변형을 이름상 모호함 없이 지칭할 수 있게 합니다.

그러나 등록된 번호에는 협상 전사(Transcription)가 담겨 있지 않습니다. 공통 인터페이스와 AEAD 레지스트리를 정의한RFC 5116은 알고리즘을 등록하는 것이 그 알고리즘을 승인하거나 보안을 보증하는 것은 아니라고 경고합니다. 이 인터페이스는 재사용 방지 정책이나 접근 제어도 정하지 않습니다. 이러한 결정은 프리미티브를 호출하는 프로토콜과 그 배포에 속합니다.

RFC 10032는 정의, 매개변수, 운영 권고, 테스트 벡터를 제공합니다. TLS, IPsec, QUIC, 스토리지, 사설 채널에 대한 단일 협상을 정하지는 않습니다. 각 프로필은 AEGIS를 제공할지, 선택을 어떻게 표현할지, 어떤 태그 길이를 쓸지, 키와 nonce를 어떻게 만들지, 어떤 바이트가 연관 데이터인지, 인증 실패 시 무엇을 할지를 각자 결정해야 합니다.

따라서 “라이브러리가 AEGIS를 지원한다”와 “이 세션은 AEGIS-128X2를 이 파라미터로 사용했다”는 서로 다른 진술입니다. 전자는 능력을 기술합니다. 후자는 합의와 실행에 대한 증거를 요구합니다.

RFC의 편집상 등급이 중요하다

RFC 10032는 2026년 9월 IRTF 스트림에서 Informational 등급으로 발행되었습니다. CFRG의 합의를 반영하지만, 문서 자체의 상태는 IETF의 표준이나 산출물이 아니며 연구 결과가 배포에 부적합할 수 있다고 명시하고 있습니다.

이는 기술적 저평가가 아닙니다. 권한과 검토의 유형에 대한 정보입니다.RFC 5743은 연구 그룹에서의 준비, IRSG 검토, IESG의 충돌 확인을 설명합니다.RFC 7841은 이 경로를 IETF Standards Track이 받는 폭넓은 검토와 승인과 구별합니다.

네 가지 사실을 분리해서 유지해야 합니다. CFRG가 연구 합의에 도달했고; IRSG가 발행을 승인했으며; IESG가 표준화와의 충돌 가능성을 검토했고; IANA가 고유 식별자를 예약했다. 어느 것도 프로토콜의 결정, 제품의 기본값, 두 단말의 선택을 기록하지 않습니다.

IANA 공개 페이지는 9월 20일 기준 여섯 개 코드를 제공했지만, 참조 열에는 여전히 초안 18이 표시되어 있었고 페이지에는 7월 7일의 갱신 사항이 명시되어 있었습니다. 이는 무효성의 증거가 아닙니다. 발행과 레지스트리 상태를 별도로 포착해야 하는 이유를 보여주는 날짜가 기록된 스냅샷입니다.

두 피어가 코드 32에서는 일치하고 케이블에서는 불일치할 수 있다

AEGIS-128L은 128비트 키와 nonce를 사용하고, AEGIS-256은 둘 다 256비트를 사용합니다. 두 알고리즘 모두 128비트 또는 256비트 인증 태그를 허용합니다. IANA의 여섯 개 이름은 계열과 필요한 경우 병렬성 수준을 식별하지만, 태그 길이는 포함하지 않습니다.

이 누락은 기술적 영향을 갖습니다. RFC 10032는 128비트 태그에 대한 커밋 작업을 약 2^64로, 256비트 태그에 대해서는 약 2^128로 추정하며, 이는 서로 다른 키 또는 nonce로 동일한 튜플이 검증되는 상황에 대한 성질에 기반합니다. 두 피어가 코드 32를 선언하면서도 서로 다른 암호문–태그 한계를 기대할 수 있습니다. 이름은 일치하지만 케이블 프로필은 일치하지 않습니다.

프레이밍도 확정해야 합니다. 사양은 암호문과 태그를 분리하거나 태그를 암호문 바로 뒤에 붙이는 방식을 허용합니다. “AEGIS-128L”만 적힌 영수증은 수신자가 몇 비트를 읽었는지, 경계를 어떻게 결정했는지 알려주지 않습니다.

연관 데이터는 또 다른 차원입니다. RFC 5116은 주소, 포트, 시퀀스, 버전과 같은 평문 필드를 언급합니다. RFC 10032는 공격자가 이 데이터를 통제하지 않는다는 제약 아래 완전한 커밋 성질을 정식화하고, 더 강한 주장이 필요할 때 추가 구성을 제시합니다. 필드의 정확한 목록, 순서, 길이, 버전, 도메인 분리는 프로토콜의 증거에 포함되어야 합니다.

그래프 속의 X4는 연결 속의 X4가 아니다

AEGIS-128X와 AEGIS-256X는 넓은 벡터 레지스터와 벡터 AES 명령을 활용하려 합니다. X2와 X4는 2단계와 4단계의 병렬성을 표현합니다. 그 이득은 아키텍처와 구현에 의존합니다.

규범적 주의사항은 명확합니다. 프로토콜은 모든 당사자가 해당 변형에 합의한 경우에만 병렬 형태를 선택해야 합니다. AEGIS-128L과 AEGIS-256은 기본 옵션으로 유지되어야 하며, 구현은 X2와 X4를 생략할 수 있습니다.

따라서 매력적인 벤치마크가 호환성을 만들지는 않습니다. 원격 피어는 기본 형태만 갖고 있을 수 있습니다. 배포된 바이너리는 X 경로 없이 컴파일되었을 수 있습니다. 가상 머신 마이그레이션은 보이는 명령을 바꿀 수 있습니다. 디스패처는 구성이 여전히 “AEGIS”를 표시하더라도 예비 경로를 선택할 수 있습니다.

유용한 테스트는 세 층위를 구분합니다. 프로토콜이 무엇을 제안하고 선택했는지; 각 단말이 정확히 어떤 능력을 갖고 있었는지; 프로세스가 실제로 어떤 경로를 실행했는지. 단일 지원 표시는 이 층위를 혼합하고 실패 지점을 가립니다.

nonce의 고유성에는 주인이 필요하다

암호화에 대해 RFC 10032는 동일한 키 아래에서 nonce를 반복하지 않을 것을 요구하며, 태그 길이가 바뀌더라도 마찬가지입니다. 재사용은 즉시 두 메시지의 XOR을 드러냅니다. nonce는 공개되거나 예측 가능할 수 있으며, 카운터나 긴 주기를 가진 다른 생성기에서 나올 수 있습니다.

무작위 nonce를 쓰는 경우 128비트 계열은 충돌 확률이 표시된 약 2^-33 수준에서 키당 최대 2^48개 메시지를 허용합니다. 256비트 계열에 대해 문서는 실용적인 무작위 한계가 없다고 서술합니다. 이는 고유성 규칙을 없애거나 그 자체로 안전한 운용을 만들지 않습니다.

배포는 여전히 고유성 도메인, 키 시대(epoch), 재시작 대비 지속성, 무작위 소스, 샤드 간 분배, 복원 또는 복제 감지가 필요합니다. 동일한 이미지에서 복원된 두 프로세스는 같은 다음 값을 자신의 것으로 여길 수 있습니다. 필드 크기는 이 충돌을 해결하지 않습니다.

키에는 유사한 이력이 필요합니다. 생성 또는 유도, 프로토콜에 결합하는 컨텍스트, 시대의 시작과 종료, 식별자, 사용자 간 분리, 파기. 임시 키가 내부 상태 초기화 후 삭제될 수 있다는 점은 선택한 구현에서 검증할 성질이며, RFC를 인용한다고 자동으로 따라오지 않습니다.

벡터는 프리미티브를 검증할 뿐 운용을 검증하지 않는다

RFC 10032에는 AES 라운드, 기본 알고리즘, X2/X4 변형, MAC 형태에 대한 광범위한 벡터가 있습니다. 이는 바이트 순서, 패딩, 부분 블록, 태그 오류를 잡아냅니다. 독립 구현 간 비교는 가치 있는 방어입니다.

음성 테스트는 다른 질문에 답합니다. 태그, 연관 데이터 필드, nonce, 병렬 수준을 바꿔 모두 실패하는지 확인해야 합니다. 사양은 실패 시 평문과 계산된 태그를 노출하지 않을 것, 복호화 버퍼를 지울 것, 태그를 상수 시간에 비교할 것을 요구합니다. 양성 벡터를 맞히지만 인증 전에 바이트를 노출하는 가속 경로는 요구되는 동작을 유지하지 않습니다.

완벽한 테스트 배터리조차 실험실에서 끝납니다. 실제 핸드셰이크가 테스트한 스위트를 제안했다는 보장, 양 단말이 선택을 인증했다는 보장, 기대한 라이브러리가 로드되었다는 보장, 가속 경로가 활성화되었다는 보장, 카운터가 의도한 키 시대 내에 머물렀다는 보장은 없습니다.

보관 영수증을 위한 열네 가지 조각

다음 영수증은 Daniel Kade가 제안한 편집적 통제입니다. RFC 10032의 필드도, IETF·IRTF·CFRG·IANA의 적합성 인증서도 아닙니다.

첫째, 문서의 식별자, 스트림, 등급, 발행 스냅샷, 정정 사항과 IANA 스냅샷을 기록해야 합니다. 둘째, 호출 프로토콜, 버전, 스위트 프로필, 구성 세대. 셋째, 제안과 선택의 인증된 전사 또는 피어 합의에 상응하는 증거.

넷째, 숫자 코드와 기본 변형 또는 정확한 X2/X4. 다섯째, 태그 길이와 프레이밍. 여섯째, 피어의 능력과 변형이 없을 때의 동작. 일곱째, 키의 기원, 유도, 컨텍스트, 시대, 식별자, 파기.

여덟째, nonce 구성과 지속성, 고유성 도메인, 재시작 및 키당 카운터. 아홉째, 연관 데이터의 필드와 정규 직렬화. 열째, 라이브러리 빌드, CPU/벡터 경로, 폴백. 열한째, 양성 벡터, 교차 비교, 음성 테스트.

열두째, 실패 의미, 평문 억제, 상수 시간 증거, 경보. 열셋째, 한정된 세션 또는 패킷과의 연결 및 사용 텔레메트리. 열넷째, 예약 규칙, 다운그레이드 거부, 롤백 트리거, 호환 세트 이탈, 보존 기간.

어떤 조각도 다른 조각을 대체하지 않습니다. 레지스트리는 핸드셰이크를 증명하지 않고; 핸드셰이크는 카운터 지속성을 증명하지 않으며; 벡터는 로드된 바이너리를 식별하지 않고; 키 시대와 연관 데이터 규칙 없이 캡처된 데이터는 왜 그 바이트를 수락했는지 설명하지 않습니다. 영수증의 가치는 모든 것을 “지원됨”이라는 단어로 환원하지 않는 데 있습니다.

출처