Pertanyaan ini cukup lama. Tapi masih relevan jadi saya akan memberikan jawaban saya. Banyak CPU saat ini hadir dengan generator nomor acak (RNG) perangkat keras bawaan. Banyak juga sistem yang dilengkapi dengan modul platform tepercaya (TPM) yang juga menyediakan RNG. Ada juga opsi lain yang dapat dibeli tetapi kemungkinan besar komputer Anda sudah memiliki sesuatu.
Anda dapat menggunakan paket rngd from rng-utils di sebagian besar distro linux untuk menambahkan lebih banyak data acak. Misalnya pada fedora 18 yang harus saya lakukan untuk mengaktifkan penyemaian dari TPM dan CPU RNG (instruksi RDRAND) adalah:
# systemctl enable rngd
# systemctl start rngd
Anda dapat membandingkan kecepatan dengan dan tanpa rngd. Sebaiknya jalankan rngd -v -f dari baris perintah. Itu akan menunjukkan kepada Anda sumber entropi yang terdeteksi. Pastikan semua modul yang diperlukan untuk mendukung sumber Anda dimuat. Untuk menggunakan TPM, perlu diaktifkan melalui tpm-tools. perbarui :inilah cara yang bagus.
BTW, saya telah membaca di Internet beberapa kekhawatiran tentang TPM RNG yang sering dilanggar dengan cara yang berbeda, tetapi tidak membaca sesuatu yang konkret terhadap RNG yang ditemukan di chip Intel, AMD, dan VIA. Menggunakan lebih dari satu sumber akan lebih baik jika Anda benar-benar peduli dengan kualitas keacakan.
urandom bagus untuk sebagian besar kasus penggunaan (kecuali terkadang saat boot awal). Sebagian besar program saat ini menggunakan urandom, bukan acak. Bahkan openssl melakukan itu. Lihat mitos tentang urandom dan perbandingan antarmuka acak.
Baru-baru ini Fedora dan RHEL/CentOS rng-tools juga mendukung jitter entropy. Anda dapat melakukannya karena kurangnya opsi perangkat keras atau jika Anda lebih memercayainya daripada perangkat keras Anda.
PEMBARUAN: pilihan lain untuk lebih banyak entropi adalah HAVEGED (mempertanyakan kualitas). Pada mesin virtual ada kvm/qemu VirtIORNG (disarankan).
PEMBARUAN 2: Di Linux 5.6 kernel melakukan jitter entropy sendiri.
Pada sebagian besar sistem Linux, /dev/random didukung dari entropi aktual yang dikumpulkan oleh lingkungan. Jika sistem Anda tidak mengirimkan data dalam jumlah besar dari /dev/random , kemungkinan besar Anda tidak menghasilkan keacakan lingkungan yang cukup untuk menjalankannya.
Saya tidak yakin mengapa Anda berpikir /dev/urandom adalah "lebih lambat" atau kualitas yang lebih tinggi. Itu menggunakan kembali kumpulan entropi internal untuk menghasilkan pseudorandomness - membuatnya sedikit lebih rendah kualitasnya - tetapi tidak memblokir. Umumnya, aplikasi yang tidak memerlukan kriptografi tingkat tinggi atau jangka panjang dapat menggunakan /dev/urandom andal.
Coba tunggu sebentar lalu baca dari /dev/urandom lagi. Mungkin saja Anda telah kehabisan kumpulan entropi internal membaca begitu banyak dari /dev/random , merusak kedua generator - memungkinkan sistem Anda membuat lebih banyak entropi harus mengisinya kembali.
Lihat Wikipedia untuk info lebih lanjut tentang /dev/random dan /dev/urandom .