/dev/random은 Windows 10(WSL)의 Ubuntu에서 매우 느립니다.

/dev/randomLinux에서는 /dev/urandom암호학적으로 안전한 의사 난수 생성기 입니다. 이전 버전의 Linux 커널에서는 /dev/random일단 초기화되면 충분한 추가 엔트로피가 축적될 때까지 차단되지만 그렇지 /dev/urandom않습니다. WSL2는 실제 Linux 커널이 있는 가상 머신이므로 엔트로피를 얻을 수 있는 엔트로피 소스 세트가 제한되어 있으며 대부분의 엔트로피를 호스트 시스템에 의존해야 합니다. 그러나 CSPRNG는 시작 시 충분한 엔트로피를 받는 한 안전하게 사용할 수 있습니다.

귀하의 환경에서는 CSPRNG가 Windows 시작 시 시드되지만 높은 비율로 다시 시드되지 않는 것 같습니다. 이는 괜찮지만 /dev/random원하는 것보다 더 자주 차단될 수 있습니다. 궁극적으로 이는 WSL2의 구성 문제입니다.

WSL1에는 이 문제가 없을 수 있습니다. 이 경우 /dev/random차단이 없고 시스템 CSPRNG만 사용되기 때문입니다 /dev/urandom.최신 버전의 Linux, 차단이 발생하는 유일한 /dev/random경우는 시작 시 CSPRNG를 한 번 시드하기에 충분한 엔트로피가 축적되지 않은 경우입니다. 그렇지 않으면 와 정확히 동일합니다 /dev/urandom. 풀이 제대로 초기화된다면 두 인터페이스에 합당한 보안 차이가 없기 때문에 이러한 결정이 내려졌습니다.

이러한 경우에는 측정 가능한 차이가 없기 때문에 /dev/random올바른 방법은 if ​​which가 차단되고 너무 느린 경우를 사용하는 것입니다 /dev/urandom. 이는 동일한 CSPRNG(ChaCha20 기반)의 출력이기 때문입니다. 그럼에도 불구하고 업스트림 Linux 동작은 향후 WSL2 버전에서 기본 동작이 될 가능성이 높습니다. Microsoft는 결국 최신 버전의 Linux에 병합될 것이기 때문입니다.

WSL2 Ubuntu에서는 이것을 직접 테스트하지 않았지만 얼마 전 CentOS 6 VM에서 비슷한 문제가 발생했습니다. 이 서비스를 설치하고 실행하면 haveged/dev/random 속도 저하 문제가 해결되었습니다. 아마도 시도해 볼 가치가 있을 것입니다.

Linux 풀 무작위성은 /dev/random 및 /dev/urandom 장치 인터페이스를 통해 배포됩니다. /dev/random 풀을 채우기 위한 표준 메커니즘은 수요가 높거나 사용자 상호 작용이 제한된 시스템에는 충분하지 않을 수 있습니다. 이러한 경우, /dev/random의 임의 비트 공급이 장치의 최저 워터마크 아래에 있는 한 /dev/random 풀을 채우면서 Haged가 권한 있는 데몬으로 실행될 수 있습니다.

https://manpages.ubuntu.com/manpages/focus/man8/haveged.8.html

그렇지 않으면 @bk2204가 말했듯이 /dev/urandom이 아마도 최선의 선택일 것입니다.