Struktur Internal Hash-DRBG, HMAC-DRBG, dan CTR-DRBG

Masing-masing dari ketiga mekanisme DRBG NIST mempertahankan komponen keadaan internal yang berbeda, sesuai dengan pendekatan algoritmik yang mendasarinya. Hash_DRBG menyimpan V (benih sepanjang hash) dan C (konstanta yang diturunkan dari V dan digunakan selama pembuatan keluaran). HMAC_DRBG menyimpan Kunci K (kunci rahasia sepanjang hash) dan Nilai V (nilai rantai sepanjang hash). CTR_DRBG menyimpan Kunci K (kunci AES) dan V (penghitung sepanjang blok). Ketiganya mempertahankan reseed_counter yang melacak panggilan Generate sejak pengisian benih terakhir. Ukuran keadaan menentukan jejak memori: Hash/HMAC_DRBG dengan SHA-256 menggunakan keadaan sebesar 64 byte; CTR_DRBG dengan AES-256 menggunakan 48 byte (kunci 32 byte + penghitung 16 byte).

Hash_DRBG menggunakan Hash_df (fungsi derivasi hash) untuk menurunkan keadaan dari materi entropi. Hash_df(input_string, no_of_bits_to_return) melakukan iterasi: untuk counter = 1, 2, ..., hitung H(counter || no_of_bits || input_string) dan gabungkan keluaran hingga bit yang cukup dihasilkan. Fungsi ini memperluas masukan entropi yang pendek menjadi benih seukuran keadaan. Selama Generate, fungsi keluaran menghitung W = H(0x03 || V), dengan awalan 0x03 yang membedakannya dari penggunaan hash lainnya. Siklus keluaran: data = H(0x01 || V); V = V + 1; ulangi untuk menghasilkan lebih banyak keluaran. Setelah pembuatan selesai, V diperbarui: V = V + H(0x03 || V) + C + reseed_counter. Pemisahan domain melalui byte awalan (0x01, 0x03) mencegah keluaran dari fase pembuatan disalahartikan sebagai keluaran dari fase pembaruan keadaan.

Fungsi Update milik HMAC_DRBG adalah inti dari semua perpindahan keadaan. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Jika provided_data tidak kosong: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Pembaruan dua langkah ini memastikan bahwa kunci dan nilai baru bergantung pada keadaan sebelumnya serta entropi baru apa pun. Generate: ulangi V = HMAC(K, V) dan tambahkan hasilnya ke keluaran hingga bit yang cukup dihasilkan; kemudian panggil Update dengan additional_input untuk memajukan keadaan. Keamanan HMAC_DRBG bergantung pada asumsi bahwa HMAC adalah PRF yang aman: musuh yang tidak dapat membedakan keluaran HMAC dari keluaran acak juga tidak dapat membedakan keluaran DRBG dari keluaran acak.

CTR_DRBG menggunakan Block_Cipher_df (fungsi derivasi) untuk mengolah materi benih menjadi format kunci/penghitung. Block_Cipher_df(input_string, no_of_bits) menggunakan konstruksi BCC (perangkaian penyandi blok): fungsi ini melakukan iterasi AES-CBC pada potongan masukan untuk menghasilkan keluaran dengan panjang yang diperlukan. Fungsi derivasi diperlukan untuk menangani masukan entropi dengan panjang yang bervariasi dan menyediakan pemisahan domain. CTR_DRBG tanpa fungsi derivasi (diizinkan untuk pengujian FIPS dengan masukan yang diformat secara tepat) lebih cepat, tetapi lebih sensitif terhadap persyaratan format masukan. Siklus Generate: temp = E(K, V); V = V + 1; tambahkan temp ke keluaran. Pembaruan: K || V = Block_Cipher_df(V || additional_input, seedlen); terapkan XOR dengan kunci saat ini.

Kinerja sangat bervariasi di antara berbagai jenis DRBG. Pada CPU x86_64 modern dengan AES-NI: CTR_DRBG (AES-256) mencapai sekitar 5–10 GB/s untuk keluaran acak semu—instruksi AES-NI membuat komputasi AES nyaris tanpa biaya. HMAC_DRBG (SHA-256) mencapai sekitar 200–400 MB/s—SHA-256 cepat, tetapi tidak dipercepat perangkat keras pada tingkat yang sama. Hash_DRBG (SHA-256) mencapai sekitar 100–300 MB/s. Untuk pembuatan kunci dalam jumlah besar atau penggantian penyandi aliran, CTR_DRBG jauh lebih cepat. Untuk penggunaan dengan laju rendah (pembuatan kunci sesi, derivasi nilai sekali pakai), perbedaan kinerja tidak signifikan. OpenSSL 3.0 menggunakan CTR_DRBG (AES-256) sebagai bawaan karena alasan ini.

Saat diinstansiasi, ketiga DRBG menerima personalization_string opsional yang dicampurkan dengan masukan entropi untuk membuat instans DRBG menjadi unik. Hal ini mencegah dua DRBG yang diinstansiasi secara bersamaan dengan entropi yang sama menghasilkan keluaran yang sama—keduanya berbeda berdasarkan string personalisasi. String personalisasi yang disarankan: pengenal aplikasi + ID proses + ID utas + cap waktu + pengenal perangkat keras. Meskipun dua VM menerima entropi yang sama (masalah cuplikan VM awan), string personalisasi yang berbeda memastikan aliran DRBG yang berbeda. NIST SP 800-90C menyarankan agar string personalisasi selalu digunakan. Parameter nilai sekali pakai memiliki tujuan serupa: nilai pendek dan unik yang memastikan tidak ada dua instansiasi yang dimulai dalam keadaan yang sama.

Ketiga DRBG mendukung parameter additional_input dalam panggilan Generate. Parameter ini memungkinkan pemanggil menyuntikkan konteks atau entropi tambahan ke dalam satu panggilan pembuatan tanpa pengisian benih ulang penuh. Kegunaannya: (1) menyuntikkan entropi per permintaan dari sumber entropi sekunder; (2) menyediakan konteks tingkat aplikasi (ID permintaan, cap waktu) untuk mengikat nilai yang dihasilkan dengan penggunaannya; (3) menyediakan ketahanan terhadap prediksi secara opsional dengan menyuntikkan entropi baru dari sistem operasi. Additional_input dicampurkan ke dalam keadaan DRBG sebelum pembuatan keluaran. Jika additional_input menyediakan entropi nyata, keamanan meningkat tanpa memerlukan pengisian benih ulang formal (yang melibatkan antarmuka sumber entropi dan beban tambahan terkait).

Setelah DRBG dibatalkan instansiasinya (atau saat beralih ke instans baru), keadaan internal harus dihapus secara aman dengan mengisinya menggunakan nol. Keadaan V, C (Hash_DRBG), K, V (HMAC/CTR_DRBG), serta semua variabel kerja perantara harus ditimpa dengan nol. Ini disebut penghapusan nol eksplisit dan diwajibkan dalam modul FIPS 140-3. Dalam kode C, gunakan explicit_bzero() atau SecureZeroMemory()—memset yang dioptimalkan pengompilasi mungkin dihapus sebagai optimasi penyimpanan mati sehingga materi kunci tertinggal di memori. Paket zeroize milik Rust dan solusi serupa khusus bahasa menangani hal ini secara portabel. Penghancuran kunci yang aman penting dalam konteks ketika pembuangan memori, serangan mulai dingin, atau alat pemeriksaan proses dapat mengungkap keadaan yang tersisa.

NIST menyediakan vektor pengujian Cryptographic Algorithm Validation Program (CAVP) untuk semua DRBG SP 800-90A. Jenis pengujian: (1) Pengujian jawaban yang diketahui—dengan masukan entropi tetap, nilai sekali pakai, dan string personalisasi, verifikasi bahwa keluaran yang dihasilkan cocok dengan nilai yang telah dihitung sebelumnya. (2) Pengujian pengisian benih ulang—verifikasi keadaan DRBG setelah operasi pengisian benih ulang. (3) Pengujian PR (ketahanan terhadap prediksi)—verifikasi bahwa permintaan prediction_resistance=true menghasilkan keluaran yang benar setelah entropi baru disuntikkan. Validasi CAVP diperlukan untuk pengajuan FIPS 140-3. Pustaka sumber terbuka (OpenSSL, mbedTLS) menyertakan vektor pengujian CAVP dalam rangkaian pengujian regresinya untuk mendeteksi kemunduran pada implementasi DRBG.

Implementasi DRBG menghadapi risiko saluran samping yang halus di luar model keamanan algoritmik. Serangan pengaturan waktu tembolok terhadap AES (dalam CTR_DRBG tanpa AES-NI) dapat membocorkan materi kunci putaran; AES-NI menghilangkan risiko ini dengan melakukan komputasi dalam register tanpa pencarian tabel. HMAC_DRBG menggunakan HMAC secara internal, yang berjalan dalam waktu konstan jika SHA-256 yang mendasarinya juga berjalan dalam waktu konstan—SHA-256 umumnya dianggap berjalan dalam waktu konstan karena tidak memiliki percabangan yang bergantung pada data. Saluran samping fisik (analisis daya, radiasi EM) terhadap perangkat keras penghasil DRBG menjadi perhatian pada kartu pintar dan perangkat IoT, dan ditangani dengan implementasi penyamaran. Serangan pencadangan keadaan: jika penyerang dapat membaca keadaan DRBG melalui kerentanan pengungkapan memori (seperti Heartbleed), semua keluaran mendatang akan terbobol hingga pengisian benih ulang berikutnya dengan entropi baru.

Jika keadaan DRBG disusupi (misalnya melalui kerentanan pengungkapan memori), pemulihan memerlukan: (1) Mendeteksi penyusupan—kebocoran keadaan DRBG tidak terlihat dengan sendirinya; diperlukan pemantauan eksternal atau pemeriksaan integritas. (2) Mengisi benih ulang dengan entropi baru dari sumber tepercaya yang tidak terlibat dalam penyusupan. (3) Mengganti kunci semua materi kriptografis yang diturunkan dari DRBG yang disusupi (kunci sesi, kunci penandatanganan yang dihasilkan sejak pengisian benih ulang terakhir yang sehat). (4) Untuk implementasi perangkat lunak, memulai ulang proses menyediakan instansiasi DRBG yang bersih. SP 800-90C menyarankan sumber entropi berantai—jika salah satu sumber disusupi, gabungannya tetap memberikan keamanan selama sumber lainnya menyediakan entropi nyata.

Hash_DRBG menggunakan hashing iteratif dengan Hash_df untuk derivasi, dan menghasilkan keluaran melalui siklus H(0x01 || V). HMAC_DRBG menggunakan HMAC sebagai PRF dengan fungsi Update dua langkah (kunci lalu nilai) yang memberikan reduksi keamanan yang jelas. CTR_DRBG menggunakan AES dalam mode penghitung dengan Block_Cipher_df, dan mencapai 5–10 GB/s pada perangkat keras AES-NI. Ketiganya menerima personalization_string saat instansiasi untuk keunikan instans dan additional_input pada setiap pembuatan untuk pengikatan konteks. Vektor pengujian CAVP memvalidasi implementasi. Keadaan harus dihapus dengan aman menggunakan nol setelah digunakan. Kompromi keadaan memerlukan pengisian benih ulang dengan entropi baru dan penggantian kunci materi yang diturunkan.