Random Number Generator

현재 시각만으로 비밀값을 만드는 지갑을 생각해 보세요. 결과는 복잡해 보여도, 생성 시각을 아는 사람은 훨씬 적은 후보만 시험하면 됩니다. RFC 4086은 바로 이런 예측 가능한 입력을 경고합니다. 게임이나 시뮬레이션에 적합한 생성기가 키 생성에도 적합한 것은 아닙니다. 통계적 분포가 좋아도 그것만으로 안전성이 입증되지는 않습니다. [2]

보통 여러 부분이 함께 작동합니다. 원천이 불확실성을 공급하고 필요에 따라 그 출력을 처리하면, 암호학적 결정론적 생성기가 비밀 내부 상태에서 추가 값을 만듭니다. 결정론적이라는 말은 내부 상태와 입력이 같으면 결과도 같다는 뜻입니다. 그래서 내부 상태를 비밀로 지켜야 합니다. 앱은 시스템 인터페이스로 이 값을 요청합니다. 따라서 반환되는 비트마다 새로운 물리적 측정이 필요한 것은 아닙니다. NIST SP 800-90C는 90A의 생성기와 90B의 원천을 결합하는 방법을 설명합니다. [1]

BIP39에서는 첫 단어가 나오기 전부터 지갑 복원의 바탕이 만들어집니다. 생성기가 먼저 128~256비트의 초기 엔트로피를 만듭니다. 비트는 영 또는 일을 나타내는 기본 정보 단위이며, 중요한 것은 공격자가 그 배열을 예측할 수 없어야 한다는 점입니다. 여기에 일부 기록 오류를 찾아내는 짧은 값인 체크섬을 더한 뒤 전체를 복구 단어로 바꿉니다. 추가 비밀 문자열인 passphrase를 설정할 수도 있습니다. PBKDF2 함수는 이 입력들로부터 512비트 seed를 유도합니다. 이는 지갑의 키를 파생시키는 비밀 시작값입니다. 출력을 늘리거나 체크섬을 붙여도 부족한 무작위성을 채울 수는 없습니다. 복구 단어를 직접 고르지 말아야 하는 이유입니다. [6]

장치는 잡음 원천이 같은 값을 반복하는 등의 고장을 감지할 수 있어야 합니다. 그래서 NIST SP 800-90B는 시작할 때와 작동 중에 원천을 검사하고, 발견한 고장에 대응하도록 요구합니다. 오류를 무시한 채 출력을 검증된 난수로 계속 취급해서는 안 됩니다. 이 검사는 원천을 감시할 뿐, 지갑 전체의 안전을 보장하지는 않습니다. [3]

결정론적 생성기는 이후 결과를 계산할 내부 상태를 보관합니다. NIST SP 800-90A는 초기화, 생성, 새로운 엔트로피 보충(reseed), 종료를 설명합니다. 상태가 유출됐다면 생성기를 한 번 더 호출하는 것만으로 안전성이 회복되지 않을 수 있습니다. 적절한 절차와 공격자가 모르는 새 엔트로피가 필요합니다. 그렇다고 이미 유출된 키를 공격자의 손에서 되찾는 것은 아닙니다. [7]

직접 RNG를 프로그래밍할 필요는 없습니다. 해당 지갑 버전의 생성 방식과 오류 처리가 문서로 설명돼 있는지 살펴보세요. “하드웨어”나 “오프라인”이라는 말만으로 이를 입증할 수는 없습니다. 검토에는 원천, 알고리즘, 초기화, 앱 인터페이스가 포함돼야 합니다. 제대로 만든 비밀값도 나중에 백업을 공개하면 보호를 잃습니다. [1] [2]

Linux의 getrandom()은 기본적으로 urandom 초기화를 기다립니다. GRND_NONBLOCK을 사용하면 기다리는 대신 EAGAIN을 반환할 수 있습니다. 초기화 후 urandom에 256바이트 이하를 요청하면 시그널로 중단되지 않고 전체를 읽는 것이 보장됩니다. 더 큰 요청에는 이 보장이 없습니다. 프로그램은 반환 상태와 실제 수신한 바이트 수를 올바르게 확인해야 합니다. [4]

Web Crypto의 getRandomValues()는 지원되는 정수 배열을 암호학적으로 강한 값으로 채웁니다. 65536바이트를 넘으면 QuotaExceededError가 발생합니다. 지원되는 알고리즘의 키에는 명세가 generateKey()를 권장하지만, 이는 범용 비트코인 지갑 생성기가 아닙니다. API를 올바르게 써도 페이지의 신뢰성이 입증되지는 않습니다. 페이지 코드가 생성된 비밀값에 접근할 수 있기 때문입니다. [5]