Dalaman Hash-DRBG, HMAC-DRBG dan CTR-DRBG

Setiap satu daripada tiga mekanisme DRBG NIST mengekalkan komponen keadaan dalaman yang berbeza, selaras dengan pendekatan algoritma asasnya. Hash_DRBG menyimpan V (benih sepanjang cincangan) dan C (pemalar yang diterbitkan daripada V dan digunakan semasa penjanaan keluaran). HMAC_DRBG menyimpan kunci K (kunci rahsia sepanjang cincangan) dan nilai V (nilai rantaian sepanjang cincangan). CTR_DRBG menyimpan kunci K (kunci AES) dan V (pembilang sepanjang blok). Ketiga-tiganya mengekalkan reseed_counter yang menjejaki panggilan penjanaan sejak pembenihan terakhir. Saiz keadaan menentukan jejak memori: Hash/HMAC_DRBG dengan SHA-256 menggunakan 64 bait keadaan; CTR_DRBG dengan AES-256 menggunakan 48 bait (kunci 32 bait + pembilang 16 bait).

Hash_DRBG menggunakan Hash_df (fungsi terbitan cincangan) untuk menghasilkan keadaan daripada bahan entropi. Hash_df(input_string, no_of_bits_to_return) melakukan lelaran: bagi counter = 1, 2, ..., kira H(counter || no_of_bits || input_string) dan gabungkan keluaran sehingga bit yang mencukupi terhasil. Proses ini memanjangkan masukan entropi yang pendek menjadi benih bersaiz keadaan. Semasa Generate, fungsi keluaran mengira W = H(0x03 || V), dengan awalan 0x03 membezakannya daripada penggunaan cincangan yang lain. Gelung keluaran: data = H(0x01 || V); V = V + 1; ulangi untuk menghasilkan lebih banyak keluaran. Selepas penjanaan, V dikemas kini: V = V + H(0x03 || V) + C + reseed_counter. Pemisahan domain melalui bait awalan (0x01, 0x03) menghalang keluaran daripada fasa penjanaan daripada disalah anggap sebagai fasa pengemaskinian keadaan.

Fungsi Update HMAC_DRBG ialah teras semua peralihan 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). Kemas kini dua langkah ini memastikan kunci dan nilai baharu kedua-duanya bergantung pada keadaan sebelumnya serta sebarang entropi baharu. Generate: ulangi V = HMAC(K, V) dan tambahkan hasilnya pada keluaran sehingga bit yang mencukupi terhasil; kemudian panggil Update dengan additional_input untuk memajukan keadaan. Keselamatan HMAC_DRBG bergantung pada andaian bahawa HMAC ialah PRF yang selamat: penyerang yang tidak dapat membezakan keluaran HMAC daripada rawak juga tidak dapat membezakan keluaran DRBG daripada rawak.

CTR_DRBG menggunakan Block_Cipher_df (fungsi terbitan) untuk memproses bahan benih menjadi format kunci dan pembilang. Block_Cipher_df(input_string, no_of_bits) menggunakan binaan BCC (Perantaian Sifir Blok): ia melakukan lelaran AES-CBC terhadap kelompok masukan untuk menghasilkan keluaran dengan panjang yang diperlukan. Fungsi terbitan ini diperlukan untuk mengendalikan masukan entropi yang panjangnya berbeza-beza serta menyediakan pemisahan domain. CTR_DRBG tanpa fungsi terbitan (dibenarkan untuk ujian FIPS dengan masukan yang diformatkan tepat) lebih pantas tetapi lebih sensitif terhadap keperluan format masukan. Gelung Generate: temp = E(K, V); V = V + 1; tambahkan temp pada keluaran. Update: K || V = Block_Cipher_df(V || additional_input, seedlen); gunakan XOR dengan kunci semasa.

Prestasi berbeza dengan ketara antara jenis DRBG. Pada CPU x86_64 moden dengan AES-NI: CTR_DRBG (AES-256) mencapai kira-kira 5–10 GB/s keluaran pseudorawak — arahan AES-NI menjadikan pengiraan AES hampir tanpa kos. HMAC_DRBG (SHA-256) mencapai kira-kira 200–400 MB/s — SHA-256 pantas tetapi tidak dipercepatkan perkakasan pada tahap yang sama. Hash_DRBG (SHA-256) mencapai kira-kira 100–300 MB/s. Untuk penjanaan kunci pukal atau penggantian sifir strim, CTR_DRBG jauh lebih pantas. Untuk penggunaan kadar rendah (penjanaan kunci sesi, penerbitan nilai sekali guna), perbezaan prestasi tidak ketara. OpenSSL 3.0 menggunakan CTR_DRBG (AES-256) sebagai lalai atas sebab ini.

Semasa pemulaan, ketiga-tiga DRBG menerima personalization_string pilihan yang dicampurkan dengan masukan entropi untuk menjadikan setiap instans DRBG unik. Ini menghalang dua DRBG yang dimulakan serentak dengan entropi yang sama daripada menghasilkan keluaran yang sama — kedua-duanya berbeza berdasarkan rentetan pemperibadian. Rentetan pemperibadian yang disyorkan: pengecam aplikasi + ID proses + ID bebenang + cap masa + pengecam perkakasan. Walaupun dua VM menerima entropi yang sama (masalah petikan VM awan), rentetan pemperibadian yang berbeza memastikan strim DRBG yang berbeza. NIST SP 800-90C mengesyorkan supaya sentiasa menggunakan rentetan pemperibadian. Parameter nilai sekali guna mempunyai tujuan yang serupa: nilai pendek yang unik untuk memastikan tiada dua pemulaan bermula dalam keadaan yang sama.

Ketiga-tiga DRBG menyokong parameter additional_input dalam panggilan Generate. Parameter ini membolehkan pemanggil menyuntik konteks atau entropi tambahan ke dalam satu panggilan penjanaan tanpa pembenihan semula penuh. Kegunaannya: (1) menyuntik entropi bagi setiap permintaan daripada sumber entropi sekunder; (2) menyediakan konteks pada peringkat aplikasi (ID permintaan, cap masa) untuk mengikat nilai yang dijana pada penggunaannya; (3) menyediakan rintangan ramalan pilihan dengan menyuntik entropi baharu daripada sistem pengendalian. Additional_input dicampurkan ke dalam keadaan DRBG sebelum penjanaan keluaran. Jika additional_input menyediakan entropi sebenar, keselamatan bertambah baik tanpa memerlukan pembenihan semula rasmi, yang melibatkan antara muka sumber entropi dan overhed berkaitan.

Selepas DRBG dinyahmulakan (atau apabila beralih kepada instans baharu), keadaan dalaman mesti dinolkan dengan selamat. Keadaan V, C (Hash_DRBG), K, V (HMAC/CTR_DRBG) dan semua pemboleh ubah kerja perantaraan mesti ditulis ganti dengan sifar. Proses ini dipanggil penolkan eksplisit dan diwajibkan dalam modul FIPS 140-3. Dalam kod C, gunakan explicit_bzero() atau SecureZeroMemory() — memset yang dioptimumkan oleh pengompil mungkin dialih keluar sebagai pengoptimuman stor mati, lalu meninggalkan bahan kunci dalam memori. Pustaka zeroize Rust dan penyelesaian khusus bahasa yang serupa mengendalikan perkara ini secara mudah alih. Pemusnahan kunci yang selamat penting dalam konteks yang membolehkan longgokan memori, serangan but sejuk atau alat pemeriksaan proses mendedahkan keadaan yang tertinggal.

NIST menyediakan vektor ujian Program Pengesahan Algoritma Kriptografi (CAVP) untuk semua DRBG SP 800-90A. Jenis ujian: (1) Ujian Jawapan Diketahui (KATs) — dengan masukan entropi, nilai sekali guna dan rentetan pemperibadian yang tetap, sahkan bahawa keluaran yang dijana sepadan dengan nilai yang telah dikira. (2) Ujian pembenihan semula — sahkan keadaan DRBG selepas operasi pembenihan semula. (3) Ujian PR (Rintangan Ramalan) — sahkan bahawa permintaan prediction_resistance=true menghasilkan keluaran yang betul selepas suntikan entropi baharu. Pengesahan CAVP diperlukan untuk penghantaran FIPS 140-3. Pustaka sumber terbuka (OpenSSL, mbedTLS) menyertakan vektor ujian CAVP dalam himpunan ujian regresi masing-masing untuk mengesan kemerosotan dalam pelaksanaan DRBG.

Pelaksanaan DRBG berdepan risiko saluran sisi yang halus di luar model keselamatan algoritma. Serangan pemasaan cache terhadap AES (dalam CTR_DRBG tanpa AES-NI) boleh membocorkan bahan kunci pusingan; AES-NI menghapuskan risiko ini dengan melakukan pengiraan dalam daftar tanpa carian jadual. HMAC_DRBG menggunakan HMAC secara dalaman, yang berjalan dalam masa malar jika SHA-256 asas juga berjalan dalam masa malar — SHA-256 umumnya dianggap berjalan dalam masa malar kerana tiada cabang yang bergantung pada data. Saluran sisi fizikal (analisis kuasa, sinaran EM) terhadap perkakasan yang menghasilkan DRBG membimbangkan bagi kad pintar dan peranti IoT, lalu ditangani dengan pelaksanaan bertopeng. Serangan sandaran keadaan: jika penyerang boleh membaca keadaan DRBG melalui kelemahan pendedahan memori (seperti Heartbleed), semua keluaran masa hadapan terjejas sehingga pembenihan semula seterusnya dengan entropi baharu.

Jika keadaan DRBG terjejas (contohnya melalui kelemahan pendedahan memori), pemulihan memerlukan: (1) Mengesan pendedahan — kebocoran keadaan DRBG tidak jelas dengan sendirinya; pemantauan luaran atau pemeriksaan integriti diperlukan. (2) Menjana benih semula dengan entropi baharu daripada sumber dipercayai yang tidak terlibat dalam pendedahan tersebut. (3) Menukar kunci semua bahan kriptografi yang diterbitkan daripada DRBG yang terjejas (kunci sesi, kunci tandatangan yang dijana sejak pembenihan semula terakhir yang sihat). (4) Bagi pelaksanaan perisian, memulakan semula proses menyediakan pemulaan DRBG yang bersih. SP 800-90C mengesyorkan sumber entropi berantai — jika satu sumber terjejas, gabungan tersebut masih menyediakan keselamatan selagi sumber yang lain menyediakan entropi sebenar.

Hash_DRBG menggunakan pencincangan berulang dengan Hash_df untuk penerbitan, dan menghasilkan keluaran melalui gelung H(0x01 || V). HMAC_DRBG menggunakan HMAC sebagai PRF dengan fungsi Update dua langkah (kunci kemudian nilai), yang memberikan jaminan keselamatan yang jelas. CTR_DRBG menggunakan AES dalam mod pembilang dengan Block_Cipher_df, lalu mencapai 5–10 GB/s pada perkakasan AES-NI. Ketiga-tiganya menerima personalization_string semasa pemulaan untuk memastikan keunikan instans dan additional_input bagi setiap penjanaan untuk mengikat konteks. Vektor ujian CAVP mengesahkan pelaksanaan. Keadaan mesti dinolkan dengan selamat selepas digunakan. Pendedahan keadaan memerlukan pembenihan semula dengan entropi baharu dan penukaran kunci bahan terbitan.