nonce와 AAD를 JSON으로 저장할 때 어떤 바이트 계약을 고정해야 하나요?

고정할 것은 JSON의 의미가 아니라 암호화와 복호화가 만드는 정확한 bytes입니다. 필드명, UTF-8 인코딩, nonce·ciphertext의 binary 표현(base64url인지 hex인지), 길이·tag 경계, 숫자 타입과 표현, AAD 필드 순서와 schema version을 명시합니다. 암호화 시 tenant=t1,purpose=invoice를 특정 순서로 만들었다면 복호화도 같은 canonical serializer를 써야 합니다.

한 구현이 {"tenant":"t1","purpose":"invoice"}를 AAD로 만들고 다른 구현이 key 순서를 바꾸면 객체는 같아 보여도 tag가 실패합니다. 숫자 1, 1.0, 큰 정수의 문자열화도 같습니다. canonical JSON이나 길이 prefix가 붙은 고정 binary encoding을 선택하고 test vector로 언어·라이브러리 교체 때 bytes를 비교합니다.

저장 레코드에는 algorithm/version, key ID, nonce, ciphertext+tag, AAD 재구성 메타데이터를 둡니다. nonce가 AEAD에 의해 내부 인증된다고 해서 포맷의 transport 표현을 생략할 수 있는 것은 아닙니다. RFC 5116은 encoding을 정하지 않으므로 canonicalization은 애플리케이션 계약입니다. open 실패 시 JSON 의미를 근거로 fallback하지 않습니다.

바이트 계약은 여러 언어가 참여할 때 특히 중요합니다. JavaScript의 숫자와 다른 언어의 정수 타입이 다르면 큰 정수나 1.0이 서로 다른 표현으로 변할 수 있고, base64와 base64url은 패딩 규칙도 다를 수 있습니다. 그래서 포맷 버전과 알고리즘 식별자를 먼저 읽고, 허용된 길이와 문자 집합을 확인한 뒤 bytes를 복원합니다. 구 버전 serializer를 계속 읽어야 한다면 버전별 test vector를 유지하고, 새 레코드는 새 규칙으로만 쓰는 이행 기간을 둡니다.