/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正しい方法はifwhichがブロックされて遅すぎる場合を使用することです/dev/urandom。これは、同じCSPRNG（ChaCha20ベース）の出力であるためです。それにもかかわらず、アップストリームLinuxの動作は、将来のWSL2バージョンでデフォルトの動作になる可能性が高いです。マイクロソフトは最終的に最新バージョンの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がおそらく最良の選択でしょう。