it-swarm-id.com

Berapa lama nonce acak harus?

NIST menyediakan pedoman yang baik tentang panjang kunci dan hash untuk berbagai algoritma . Tapi saya tidak melihat apapun secara khusus pada panjang acak atau pseudo-acak nonce (angka yang digunakan sekali).

Jika ada satu jawaban bagus untuk berbagai kegunaan, saya ingin melihatnya. Tetapi untuk membuat ini konkret, saya akan menggunakan situasi "reset kata sandi melalui email" yang umum, di mana server menghasilkan URL dengan komponen jalur pseudo-acak. Tampaknya agak mirip dengan Otentikasi HTTP Digest, di mana contoh dalam RFC tampaknya memiliki 136 bit (dcd98b7102dd2f0e8b11d0f600bfb0c093).

Saya perhatikan bahwa banyak orang tampaknya menggunakan UUID versi 4 (yang menyediakan 122 bit pseudo-acak) atau ini, seperti yang dibahas di Apakah GUID aman untuk token satu kali? , meskipun pengguna harus berhati-hati dengan penggunaan versi UUID sebelumnya yang jauh lebih mudah diprediksi, dan serangan lokal yang terus-menerus pada generator nomor acak Windows yang sebagian besar ditambal pada tahun 2008.

Tetapi mengabaikan risiko terlibat dalam versi dan implementasi UUID, berapa banyak bit pseudo-acak yang harus dimasukkan dalam URL?

35
nealmcb

64-bit nonce kemungkinan lebih dari cukup untuk tujuan praktis, jika 64 bit adalah kualitas acak crypto.

Mengapa 64 bit sudah cukup? Biarkan saya menjelaskan alasan yang dapat Anda gunakan untuk menjawab pertanyaan ini. Saya akan menganggap ini adalah URL terbatas waktu sekali pakai; setelah digunakan sekali, itu tidak lagi valid, dan setelah beberapa saat (3 hari, katakanlah), itu kedaluwarsa dan tidak lagi valid. Karena nonce hanya berarti bagi server, satu-satunya cara penyerang dapat mencoba menebak adalah mengirim tebakan 64-bit ke server dan melihat bagaimana server merespons. Berapa banyak tebakan yang bisa dicoba oleh penyerang dalam waktu sebelum waktu habis? Katakanlah penyerang dapat membuat 1000 permintaan HTTP per detik (itu penyerang yang cukup gemuk); maka penyerang dapat membuat sekitar 1000 * 3600 * 24 * 3 = 228 menebak dalam periode 3 hari. Setiap tebakan memiliki 1/264 peluang menjadi benar. Oleh karena itu, penyerang memiliki paling banyak 1/236 peluang melanggar skema. Itu harus lebih dari cukup aman untuk sebagian besar pengaturan.

23
D.W.

Pertama, perkirakan jumlah maksimum penggunaan yang akan didapat sistem Anda (berapa kali jumlah acak akan dihasilkan). Selanjutnya, tentukan tingkat keamanan yang dapat diterima, yaitu, seberapa tidak mungkin suatu nonce adalah duplikat dari yang lama. Hitung jumlah penggunaan dalam bit, gandakan itu dan tambahkan ketidakmungkinan yang Anda butuhkan dalam bit dan Anda memiliki panjang nonce Anda.

Contoh dari AES-GCM dengan IV acak. Jumlah doa yang diizinkan dengan IV acak untuk kunci tertentu adalah 232. Probabilitas bahwa IV digunakan kembali harus kurang dari 2-32. Panjang nonce yang diperlukan untuk ini adalah 32 × 2 + 32 == 96 bit.

Jika, secara hipotesis, Anda ingin dapat menghasilkan 296 paket, masing-masing dengan nonce acak dan ingin probabilitas duplikat nonce menjadi kurang dari 2-32, Anda memerlukan nonce yang 96 × 2 + 32 == 224 bit.

Membandingkan ini dengan jawaban di atas 64 bit ... jika Anda memiliki lebih dari 216 (65536) menggunakan sistem Anda, probabilitas memiliki duplikat nce pada waktu itu lebih dari 2-32 (lebih dari 1 dalam 4 miliar, skala pendek). Ini mungkin cukup dapat diterima, tergantung pada persyaratan keamanan Anda, atau mungkin juga tidak.

Sebagai satu ukuran cocok untuk semua jawaban - UUID acak yang disebutkan adalah solusi yang cukup oke.

Perhatikan bahwa nilai-nilai ini adalah perkiraan, dan perhitungan yang lebih akurat jauh lebih kompleks.

7
Nakedible