AuditableRandom은 RFC 8439 ChaCha20(20 라운드) keystream을 직접 구현한 라이브러리이며,
독립적인 외부 암호 감사를 받지 않았다. LICENSE(BSD-3-Clause)에 따라 어떤 보증도
없이 "있는 그대로(AS IS)" 제공되며, 사용에 따른 위험은 전적으로 사용자가 부담한다. 고위험·규제
환경에 적용하기 전에는 직접 검토·검증할 것을 권한다.
이 라이브러리의 핵심 가치는 재현성이다. 이는 의도된 기능이며, 보안상 다음 전제를 동반한다.
- 비밀 seed가 유일한 보안 경계다. seed가 노출되면
(userId, tick)만으로 모든 출력을 바이트 단위로 재현할 수 있다. seed는 32바이트의 충분한 엔트로피 (예:RandomNumberGenerator.GetBytes(32))로 생성하고, 비밀로 관리해야 한다. - 예측 불가능성이 필요하면 seed를 절대 공개하지 말 것. 감사 목적으로 seed를 사후 공개하는 설계라면, 공개 시점 이후의 추출은 더 이상 예측 불가능하지 않다.
(seed, nonce)묶음을 재사용하지 말 것. nonce에는tick이 들어간다. system clock은 뒤로 갈 수 있으므로, 같은 seed로 재시작하는 경우 직전 실행의 최대tick을 영속화했다가Initialize(seed, resumeAfterTick:)로 넘겨 tick 겹침을 막아야 한다. (자세한 내용은 README의 "재시작 간 nonce 유일성 보장" 참조.) 멀티스레드로 추출한다면 가장 마지막에 관측한 tick이 아니라 최댓값을 영속화해야 한다. tick의 대소는 같은 스레드 안에서만 발급 순서와 일치하므로, 나중에 발급된 tick이 더 작을 수 있다. 최댓값이 아닌 값을 넘기면 재시작 후 이전 실행의 tick 구간과 겹쳐 keystream이 재사용된다.- 동시에 실행되는 프로세스(인스턴스)마다 seed를 다르게 할 것. tick은 한 프로세스 안에서만
유일하다. 같은 seed를 쓰는 서버 여러 대(수평 확장, 블루/그린 배포의 겹치는 구간 등)가 비슷한 시각에
시작하면 같은 tick을 발급할 수 있고, 그러면 같은 userId의 추출이 같은
(seed, nonce)를 써서 결과가 그대로 겹친다.resumeAfterTick은 순차 재시작만 보호하며 동시 실행은 막지 못한다. 인스턴스별 seed를 쓰려면 감사 로그에 어느 seed(인스턴스)로 추출했는지도 함께 기록해야 한다. - 재현 오버로드를 생성 경로로 쓰지 말 것.
tick을 인자로 받는 오버로드 (GetBlockChaCha20(userId, tick),Fill(userId, tick, ...), 그리고 명시 seed를 받는 같은 계열)는 감사 로그의 사후 재현 전용이다. 라이브러리가 발급한 tick이 아니라 호출자가 정한 값을 넘기면 nonce 유일성 보장이 사라져 같은(seed, nonce)로 keystream이 재사용될 수 있다. 새 난수가 필요하면 반드시 tick을 반환하는 경로(out Int64 tick)를 쓴다. - 리틀엔디안 전용. 빅엔디안 환경에서는 조용히 다른 keystream이 나와 재현이 깨지므로,
타입 초기화 시점에
PlatformNotSupportedException을 던진다.
최신 게시 버전에 대해서만 보안 수정을 제공한다. 항상 nuget.org의 최신 버전 사용을 권한다.
보안 취약점은 공개 이슈로 등록하지 말 것. 대신 GitHub의 비공개 취약점 신고 기능을 사용한다.
신고에는 영향 받는 버전, 재현 절차, 가능하면 개념 증명(PoC)을 포함해 주기 바란다. 접수된 신고는 확인 후 수정 일정과 함께 회신하며, 수정 배포 전까지 책임 있는 비공개(responsible disclosure)를 요청한다.