/ Dev / random vs / dev / urandom kullanıldığında

Ben kullanmalı mıyım /dev/randomyoksa /dev/urandom?

Hangi durumlarda birini diğerinden tercih ederim?

TL; DR

/dev/urandomEn pratik amaçlar için kullanın .

Uzun cevap, çalıştırmakta olduğunuz Unix'in lezzetine bağlıdır.

Linux

Tarihsel olarak, /dev/randomve /dev/urandomikisi de aynı anda tanıtıldı.

@DavidSchwartz belirttiği gibi bir yorum , kullanarak /dev/urandomvakaların büyük çoğunluğunda tercih edilir. O ve diğerleri ayrıca daha fazla okuma için önerdiğim makale hakkındaki/dev/urandom mükemmel Efsanelere bir bağlantı sağladı .

Özetle:

• Manpage yanıltıcı
• Her ikisi de rastgele olmak için aynı CSPRNG ile beslenir ( diyagram 2 ve 3 )
• /dev/random entropi bittiğinde bloklar
• Entropi miktarı muhafazakar bir şekilde tahmin edilir ancak sayılmaz
• /dev/urandomasla engellemeyecek, okuma /dev/randomişlemlerin yürütülmesini durdurabilir.
• Nadir durumlarda, açılıştan çok kısa bir süre sonra, CSPRNG , uygun bir şekilde ekilecek kadar yeterli entropiye sahip /dev/urandomolmayabilir ve yüksek kalitede rastlantısallık üretmeyebilir.
• CSPRNG başlangıçta düzgün bir şekilde ekilmişse entropi azalıyorsa sorun olmaz
• CSPRNG sürekli olarak yeniden ekiliyor
• Linux 4.8 ve sonrasında, /dev/urandomentropi havuzunu tüketmez (tarafından kullanılır /dev/random), ancak yukarıdan gelen CSPRNG çıkışını kullanır.
• Kullanın /dev/urandom.

Kuralın istisnaları

In Kriptografi Stack Exchange en zaman kullanılmalı /dev/randomüzerinde /dev/urandomLinux içinde @otus iki kullanım durumları verir :

1. Düşük bir entropi cihazında önyüklemeden kısa bir süre sonra, eğer uygun bir şekilde tohumlamak için yeterli entropi oluşturulmadıysa /dev/urandom.

2. Bilgi teorik güvenliği ile bir defalık pad oluşturma

Endişeleniyorsanız (1), mevcut entropiyi kontrol/dev/random edebilirsiniz .

Yapıyorsanız (2) zaten bileceksiniz :)

Not: / dev / random'dan okumanın engellenip engellenmediğini kontrol edebilirsiniz , ancak olası yarış koşullarına dikkat edin.

Alternatif: ikisini de kullanmayın!

@otus ayrıca, getrandom()sistemin /dev/urandomilk tohum entropisi kullanılamaması durumunda okunacağını ve ancak bunu engelleyeceğini belirtti.

Orada değişen sorunlar /dev/urandomkullanmakgetrandom() , ama yeni bir düşünülebilir /dev/xrandomcihaz dayalı oluşturulur getrandom().

Mac os işletim sistemi

Önemli değil, Wikipedia’nın dediği gibi :

macOS, SHA1'e dayanan 160 bit Civanperçemi kullanır . / Dev / random ve / dev / urandom arasında bir fark yoktur; her ikisi de aynı şekilde davranır. Apple iOS da Yarrow kullanıyor.

FreeBSD

Önemli değil, Wikipedia’nın dediği gibi :

/dev/urandom/dev/randomDüzgün bir şekilde ekilene kadar sadece bir link ve sadece bloklar

Bu, açılıştan sonra, FreeBSD'nin hiç bitmeyen bir rastgele iyilik akışı sağlamadan önce yeterli tohum entropisi toplanana kadar bekleyecek kadar akıllı olduğu anlamına gelir.

NetBSD

Kullanım /dev/urandom, sistem varsayarak en az bir defa okuduğu /dev/randomuygun başlangıç tohumlama sağlamak için.

RND (4) manpage diyor :

/dev/urandom Asla engelleme yapmayın.

/dev/randomBazen bloklar. Sistemin durumunun tahmin edilebilir olduğu biliniyorsa önyüklemede erken engelleyecektir.

Uygulamalar, rastgele oluşturulmuş verilere ihtiyaç duyduklarında / dev / urandom'dan okumalıdırlar, örneğin simülasyonlar için kriptografik anahtarlar veya tohumlar.

Sistemler, tahmin edilebilecek anahtarlar üretmekten kaçınmak için, internet ile konuşan veya kriptografi gerektiren herhangi bir hizmeti çalıştırmadan önce, açılışta en az bir kez / dev / random'dan dikkatli bir şekilde okumak için tasarlanmalıdır.

Geleneksel olarak, arasındaki tek fark /dev/urandomve /dev/randomçekirdek sistemde entropi yoktur düşündüğü böyle olur - /dev/randomkapalı başarısız, /dev/urandomaçık başarısız olur. Her iki sürücü dan entropi kaynak edilmiş add_disk_randomness(), add_interrupt_randomness()ve add_input_randomness(). Ayrıntılar /drivers/char/random.ciçin bakınız .

Eklemek için düzenlendi: Linux 4.8'den itibaren /dev/urandomCSPRNG kullanmak için elden geçirildi.

Ne zaman kapalı kalmalısın? Her türlü kriptografik kullanım için, özellikle DRBG'yi tohumlamak için. /dev/urandomRSA anahtarları üretirken kullanmanın ve yeterli entropiye sahip olmamanın sonuçlarını açıklayan çok iyi bir makale var . Ps ve Qs'unuzu incelemeyi okuyun .

Bu biraz "ben de" cevabını veriyor, ancak Tom Hale'in tavsiyesini güçlendiriyor. Bu tamamen Linux için geçerlidir.

• kullanım /dev/urandom
• Kullanma /dev/random

Linux Çekirdek Kripto'daki Theodore Ts'o’nun posta listesine göre, /dev/randomon yıldan beri itiraz edildi. Gönderen Re: [RFC YAMA v12 3/4] Linux Random Number Generator :

Pratik olarak hiç kimse / dev / random kullanmaz. Esasen kullanım dışı bir arayüzdür; On yıldan fazla bir süredir önerilen ana arayüzler / dev / urandom ve şimdi ise getrandom'dur (2).

Düzenli olarak test ediyoruz /dev/randomve sık sık arızalanıyor. Test üç adımı gerçekleştirir: (1) /dev/randomblokaj modunda olmayan 10K bayt sorarak boşaltın ; (2) engelleme modunda 16 bayt talep et (3) rastgele olup olmadığını (fakir adamın testi) görmek için bloğu sıkıştırmayı dene. Testin tamamlanması birkaç dakika sürer.

Sorun Debain sistemlerinde (i686, x86_64, ARM ve MIPS) çok kötü, GCC Compile Farm'dan rng-toolstest makineleri için paketi kurmalarını istedik . Gönderen gcc67 ve gcc68 rng-araçları yükleyin :

Rng araçlarının gcc67 ve gcc68'ye kurulmasını rica ediyorum. Bunlar Debian sistemleridir ve / dev / random, aygıtı kullanan kitaplıklara işkence yaparken rng araçları olmadan entropi tükenmesine uğrar.

BSD'ler ve OS X, Tamam görünüyor. Sorun kesinlikle Linux.

Ayrıca Linux'un jeneratör hatalarını kaydetmediğinden bahsetmeye değer olabilir. Girişlerin sistem günlüğünü doldurmasını istemediler. Bugüne kadar çoğu hata sessizdir ve çoğu kullanıcı tarafından algılanmaz.

Çekirdek en az bir hata mesajı basacağından durum kısa bir süre sonra değişmeli. Gönderen sessizlik derleyici uyarı ve düzeltme ırk: [YAMA] rasgele çekirdek kripto posta listesinde:

Özellikle ekledim depends on DEBUG_KERNEL. Bu, bu faydalı uyarıların yalnızca diğer çekirdek geliştiricileri etkileyeceği anlamına gelir. Muhtemelen istediğimiz tam olarak budur. İlgili çeşitli geliştiriciler, kendi alt sistemlerinden gelen bir uyarı görürse, düzeltmek için daha motive olurlar. Dağıtım çekirdeğindeki sıradan kullanıcılar, tipik olarak DEBUG_KERNEL kullanmadıklarından, uyarıları veya istenmeyen postaları hiç görmemelidir.

Tüm mesajları güvenlik mühendisliği bakış açısından bastırmanın kötü bir fikir olduğunu düşünüyorum.

Birçok insan hata ayıklama çekirdeği çalıştırmaz. Sorunları bilmek isteyen ya da bilmek isteyen kullanıcıların çoğu, bunun gerçekleştiğini anlamıyor. Düşünün, sistem problemlerini öğrenmemizin sebebi dmesg'lerden kaynaklanıyordu.

Tüm konfigürasyonlar için tüm mesajları bastırmak gerekenden daha geniş bir ağa sahiptir. Potansiyel olarak tespit edilebilecek ve düzeltilebilecek yapılandırmalar fark edilmeyecektir. Sorun gün ışığına çıkarılmazsa, sorun çözülmez.

Çekirdeğin bazı kuruluşlar için politika kararları aldığını hissediyorum. Etkin bir şekilde sabitlenemeyen donanıma sahip olanlar için, kuruluş risk sıkıntılarına göre ne yapılacağına karar vermek zorundadır. Riskle yaşamaya karar verebilirler veya donanımı yenilemeye karar verebilirler. Ancak, konuyla ilgili bilgi olmadan, işlem yapabilecek bir öğelerinin olduğunu bile fark edemezler.

Sonunda iş parçacığında sonunda ulaşılan uzlaşma, çağrı modülü başına en az bir dmesg idi.