개발자 도구 · UUID 생성기
Math.random 대 crypto.getRandomValues: 각 생성기의 작동 방식
· 작동 방식
uuid 암호화 브라우저 API
둘 다 무작위로 보이는 숫자를 반환하지만 하나는 작은 결정론적 상태 머신이고 다른 하나는 운영 체제에 의해 제공됩니다. 각각이 내부적으로 수행하는 작업과 UUID가 두 번째를 사용해야 하는 이유는 다음과 같습니다.
Math.random에서 UUID을(를) 구축하는 포럼 조각 — 보기에 괜찮아 보이고 모든 일반 테스트를 통과하는 이유
포럼 답변은 8줄의 빠른 UUID 팩토리를 제공합니다. Math.random의 값을 롤업하고 8-4-4-4-12 레이아웃으로 형식을 지정합니다. 코드는 괜찮아 보이고 모든 일반 테스트를 통과합니다. 각 식별자는 서로 다르게 나타나며 짧은 샘플에는 명확한 시각적 패턴이 표시되지 않습니다. 이는 보안에 민감한 식별자에 필요한 속성이 아닙니다. JavaScript는 Math.random을 의사 난수 소스로 지정하지만 예측에 대한 암호화 저항이 필요하지 않습니다. 적절한 작업에는 시뮬레이션, 게임 및 셔플링이 포함됩니다. 식별자가 액세스, 개체 검색 또는 기타 적대적 결정에 영향을 미칠 수 있으면 외관은 더 이상 증거가 아닙니다. 생성기의 문서화된 계약은 그럴듯해 보이는 출력 페이지보다 더 중요합니다.
Inside Math.random — 비밀이 아닌 속도와 통계적 확산을 위해 설계된 고정된 내부 상태를 가진 시드 의사 난수 알고리즘입니다.
Math.random은 암호화 생성기로 지정되지 않기 때문에 해당 출력은 미래 값이 관찰자에게 숨겨져 있다는 증거로 처리되어서는 안 됩니다. crypto.getRandomValues에는 다른 플랫폼 계약이 있습니다. 즉, 암호화가 강력한 값으로 정수 유형의 배열을 채웁니다. Web Crypto 사양은 정확한 생성기를 사용자 에이전트에 맡기므로 애플리케이션 코드는 특정 알고리즘, 시드 크기 또는 엔트로피 장치를 요구해서는 안 됩니다. ToolAcre는 지원되는 경계만 필요합니다. 브라우저는 안전한 임의 바이트를 제공하고 JavaScript는 채워진 Uint8Array를 수신하며 UUID 코드는 버전 및 변형 필드를 설정합니다. 이 명령문은 내부 구현이 다른 브라우저 간에 유용하고 이식 가능합니다.
출력을 관찰하면 상태가 드러날 수 있는 이유 - 작은 상태가 일련의 값을 통해 누군가가 다음 값을 예측할 수 있음을 의미하는 방식
애플리케이션 코드는 JavaScript PRNG 상태를 구현하거나 노출하는 대신 getRandomValues에서 강력한 암호화 값을 받습니다. 보안 차이는 실제 시스템에서 나타납니다. Math.random에서 구축된 식별자는 네트워크(또는 이전 UUID가 표시되는 시스템)를 읽을 수 있는 공격자가 다음 UUID를 예측할 수 있기 때문에 예측 결과가 발생할 때마다 적합하지 않습니다. crypto.getRandomValues의 v4 UUID는 그 자체로는 인증 토큰이 아니지만(만료, 해싱, 속도 제한이 필요함) 생성기는 예측을 방지하도록 설계되었습니다. ToolAcre는 보안 소스가 없는 경우 자동으로 예측 가능한 공식으로 다운그레이드하는 대신 식별자 생성을 거부합니다. Math.random은 주요 엔진에 미묘한 배포 버그가 포함되어 있습니다. 출력 시퀀스는 비밀 보유 역할에 필요한 적대적 예측 불가능성을 제공하지 않고 다양하게 보일 수 있습니다.
crypto.getRandomValues 내부 — 브라우저는 하드웨어와 시스템 엔트로피를 혼합하고 예측할 수 없도록 설계된 운영 체제의 CSPRNG를 요청합니다.
엔진별 알고리즘과 통계적 동작은 변경될 수 있습니다. 육안 검사나 일반 배포 테스트 모두 Math.random을 암호화 소스로 업그레이드하지 않습니다. 충돌 계산은 또한 명시된 공간으로부터 독립적인 출력을 가정합니다. 생성기가 상태를 반복하거나 잘못 시드되거나 결정적 고정 장치로 대체되면 해당 가정은 실패하고 공식은 더 이상 구현을 설명하지 않습니다. 두 API 모두 똑같이 불규칙해 보이는 문자열을 생성할 수 있습니다. 위협 모델은 이를 구분합니다. 예측에 저항해야 하는 값은 crypto.getRandomValues를 사용하고, 시뮬레이션 및 비적대적 셔플은 Math.random을 사용할 수 있습니다. 선택은 구두점이나 표본의 명백한 다양성이 아닌 예측의 결과에 따라 결정됩니다.
실제 사례 — 각 방법으로 동일한 수의 식별자를 생성하고 관찰자가 추론할 수 있는 내용을 비교합니다.
ToolAcre UUID 생성기는 crypto.getRandomValues를 독점적으로 사용합니다. 예측 가능한 UUID의 비용은 항상 약간 느린 생성기의 비용보다 높기 때문에 Math.random을 사용하지 않습니다. 암호화 차이는 위협 모델을 통해 측정할 수 있습니다. UUID를 위조하려는 공격자는 식별자를 직접 추측하거나 난수 생성기를 중단해야 합니다. 직접적인 추측은 이 기사에서 정량화한 비교가 아닙니다. 지원되는 결론은 Web Crypto가 암호화 무작위성을 위한 것이지만 Math.random은 그렇지 않다는 것입니다. CSPRNG와 Math.random은 서로 다른 계약을 노출합니다. 전자는 보안에 민감한 임의성을 위해 설계되었지만 후자는 그러한 약속을 전달하지 않습니다. 식별자로 Math.random을 사용하는 시스템은 암호화 속성을 잃었습니다. 이제 보안은 생성된 UUID 시퀀스를 비밀로 유지하는 데 달려 있습니다. UUID 하나라도 누출되면 전체 미래 세대가 손상됩니다.
역사적인 배포 버그 — 엔진이 질적으로 설명된 눈에 띄게 고르지 않은 출력으로 Math.random 구현을 출시했음을 상기시킵니다.
애플리케이션이 UUID를 로그, 데이터베이스 또는 버전 제어 기록에 저장하는 경우 누출은 거의 불가피합니다. ToolAcre 라이브러리는 crypto.getRandomValues 사용을 강제하고 보안 컨텍스트(HTTPS 또는 localhost)를 사용할 수 없는 경우 UUID 생성을 거부합니다. 이 설계 결정은 많은 수동 구현을 괴롭혔던 Math.random에 대한 자동 대체를 방지합니다. Node.js에서 라이브러리는 암호화 모듈을 사용합니다. 브라우저에서는 Web Crypto API를 사용합니다. 지원되는 두 경로 모두 플랫폼에서 암호화된 강력한 무작위성을 요청합니다. 엔진, 장치 및 작업 부하가 타이밍을 결정하므로 구현에서는 성능을 주장하지 않습니다. 보안 계약은 식별자에 대한 결정적인 속성입니다. 업계 표준이 crypto.getRandomValues로 정착된 이유는 UUID 오용의 짧은 역사입니다. 초기 시스템은 시스템 시간, 네트워크 인터페이스 및 하드웨어 시계를 사용하여 식별자를 생성했습니다.
여기서 다루지 않는 내용 — 시뮬레이션을 위한 생성기의 통계적 품질. 이는 예측 불가능성과는 다른 질문입니다.
시간 기반, 노드 기반 및 무작위 UUID 버전은 다양한 할당 문제를 해결합니다. 모든 이전 설계에 대해 선형 수리로 제시되어서는 안 됩니다. 4 버전의 경우 RFC 9562는 임의의 필드를 정의하고 추측 불가능성에 대해 별도로 논의합니다. 따라서 Math.random에서 마이그레이션하면 텍스트의 UUID 모양을 변경하지 않고 새로 생성된 값의 품질이 변경됩니다. 기존 식별자는 데이터베이스 키로 유지됩니다. 이를 재생성하면 참조가 중단됩니다. 새로운 값은 Web Crypto를 즉시 사용할 수 있는 반면, 승인은 모든 이전 또는 새 UUID를 권한 증명이 아닌 식별자로 계속 처리해야 합니다. 사고 대응자가 각 인구를 생산한 발전기를 알 수 있도록 컷오프를 문서화합니다.
요약: 모양이 아닌 위협에 따라 생성기를 선택합니다. ToolAcre UUID 생성기는 CSPRNG를 독점적으로 사용하며 Math.random()은 사용하지 않습니다.
유효성 검사에서는 기존(비밀 유지에 적합하지 않음) ID와 새(CSPRNG 지원) ID를 구별해야 합니다. 문서에는 전환이 기록되어야 합니다. ToolAcre 생성기는 crypto.getRandomValues UUID만 생성합니다. 다른 소스의 식별자를 검증하거나 재생성하려고 시도하지 않습니다. ToolAcre 생성기는 더 약한 임의 소스로의 다운그레이드를 거부하여 모범 사례를 보여줍니다. crypto.getRandomValues를 사용할 수 없는 경우 도구는 Math.random을 자동으로 사용하는 대신 오류를 보고합니다. 이 설계 원칙은 보안이 중요한 모든 시스템에 적용됩니다. 약한 보안 보장으로 조용히 성공하기보다는 큰 소리로 실패합니다. "UUID 생성 실패: 암호화 API를 사용할 수 없음"이 표시되는 개발자는 근본적인 문제를 해결해야 합니다(HTTPS로 업그레이드, 보안 컨텍스트 수정 또는 적절한 대체 제공). Math.random에서 구축된 UUID를 자동으로 수신하는 개발자는 시스템이 손상되었다는 징후를 전혀 알 수 없습니다. ToolAcre 라이브러리는 편의성보다 정직성을 우선시합니다.