Tomcatの起動に時間がかかりすぎる-Java SecureRandom
重複としてマークしないでください。これは、これら両方の質問のフォローアップ質問です。
私はそれを理解しています
securerandom.source=file:/dev/urandom
と
securerandom.source=file:/dev/./urandom
$Java_PATH/jre/lib/security/Java.securityはこの問題を解決します。
私の質問は、本番環境でそうしても大丈夫ですか？これはセキュリティに影響を及ぼしますか（セッションIDが予測可能になるなど）？これが安全性が低い場合、十分なエントロピーをより速く与える他の方法はありますか？
更新
私はデプロイにopenstackを使用しています（または、AWS、GCP、またはその他のクラウドプロバイダーを使用しています）。したがって、サウンドカードなどのハードウェアデバイスを追加することは私にとってオプションではありません。
適切な検索用語を使用して広範囲にグーグルした後、 DigitalOcean に関するこの素敵な記事に出くわしました。ここでは、関連する部分を引用しているだけです。
Linuxには、/ dev/randomと/ dev/urandomの2つの一般的なランダムデバイスがあります。最良のランダム性は/ dev/randomから得られます。これはブロッキングデバイスであり、出力を提供し続けるのに十分なエントロピーが利用可能になるまで待機します。エントロピーが十分であると仮定すると、/ dev/urandomから同じ品質のランダム性が見られるはずです。ただし、これは非ブロッキングデバイスであるため、エントロピープールが不足した場合でも、「ランダム」データを生成し続けます。以前のデータが繰り返される可能性がはるかに高いため、これによりランダムデータの品質が低下する可能性があります。本番サーバーで使用可能なエントロピーが少なくなると、特にこのサーバーが暗号化機能を実行するときに、多くの悪いことが起こる可能性があります。
したがって、潜在的なセキュリティリスクがあります。
エントロピープールにデータを入力するためのソリューション
Linuxはすでにさまざまなハードウェアソースから非常に高品質のランダムデータを取得していますが、ヘッドレスマシンには通常キーボードやマウスがないため、生成されるエントロピーははるかに少なくなります。ディスクおよびネットワークI/Oは、これらのマシンのエントロピー生成ソースの大部分を表しており、これらは非常にまばらな量のエントロピーを生成します。サーバーやクラウドサーバー/仮想マシンなどのヘッドレスマシンで専用のハードウェアRNGソリューションを利用できるものはほとんどないため、ビデオカードなどのハードディスクよりも「ノイズの多い」デバイスからのハードウェア割り込みを使用して追加のエントロピーを生成するユーザーランドソリューションがいくつかあります。サウンドカードなど。サーバーには通常どちらも含まれていないため、残念ながらこれもサーバーの問題であることがわかります。
解決策：
HAVEGEの原則に基づいて、以前は関連するライブラリに基づいて、havegedを使用すると、プロセッサでのコード実行時間の変動に基づいてランダム性を生成できます。同じハードウェア上の同じ環境であっても、1つのコードの実行に同じ正確な時間をかけることはほぼ不可能であるため、単一または複数のプログラムを実行するタイミングは、ランダムなソースをシードするのに適している必要があります。ハッジされた実装は、ループを繰り返し実行した後、プロセッサのタイムスタンプカウンター（TSC）の違いを使用して、システムのランダムソース（通常は/ dev/random）をシードします
Havegedのインストール方法
この記事の手順に従ってください。 https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged
誰かがこの問題を抱えているなら
デバッガーのブレークポイントをすべて削除するだけで解決しました。