Yavaş bir SecureRandom jeneratörü ile nasıl başa çıkılır?


165

Java'da kriptografik olarak güçlü rastgele sayılar istiyorsanız, kullanın SecureRandom. Ne yazık ki, SecureRandomçok yavaş olabilir. /dev/randomLinux'ta kullanıyorsa , yeterli entropinin oluşmasını bekleyebilir. Performans cezasını nasıl önlersiniz?

Herkes bu soruna bir çözüm olarak Yaygın olmayan Matematik kullandı mı?

Herkes bu performans sorununun JDK 6'da çözüldüğünü doğrulayabilir mi?


Bu, SecureRandom.generateSeed () yavaşlığıyla ilişkili gibi görünüyor . Yavaşlığı
AlikElzin-kilaka

/ Dev / urandom'a (/ dev / random değil) bakın .. Bir engelleme sorunu varsa urandom'dan rastgele bir sayı üreteci tohumu almayı düşünün.
jcalfee314

Yanıtlar:


80

Gerçek rastgele veriler istiyorsanız, ne yazık ki bunu beklemeniz gerekir. Buna bir SecureRandomPRNG tohumu da dahildir . Yaygın olmayan Matematik gerçek rastgele verileri daha hızlı toplayamaz SecureRandom, ancak belirli bir web sitesinden tohum verilerini indirmek için internete bağlanabilir. Benim tahminim bunun mümkün olandan daha hızlı olması pek mümkün /dev/randomdeğil.

Bir PRNG istiyorsanız, böyle bir şey yapın:

SecureRandom.getInstance("SHA1PRNG");

Ne dizeleri desteklenir bağlıdır SecureRandomSPI sağlayıcısına, ancak bunları kullanarak numaralandırabilmesidir Security.getProviders()ve Provider.getService().

Güneş SHA1PRNG'ye düşkündür, bu yüzden yaygın olarak bulunur. PRNG'ler gittikçe özellikle hızlı değildir, ancak PRNG'ler entropinin fiziksel ölçümü için engellemeyecek şekilde sadece sayıları ezecektir.

Bunun istisnası, setSeed()veri almadan önce arama yapmazsanız , PRNG'nin ilk kez aradığınızda next()ya da kendisini tohumlayacağıdır nextBytes(). Bunu genellikle sistemden oldukça az miktarda gerçek rastgele veri kullanarak yapar. Bu çağrı engellenebilir, ancak rastgele sayılar kaynağınızı "PID ile birlikte şimdiki zaman hash, 27 ekleyin ve en iyisini umuyoruz" herhangi bir varyantından çok daha güvenli hale getirecektir. Gereksinim duyduğunuz tek şey bir oyun için rasgele sayılarsa veya akışın gelecekte test amacıyla aynı tohumu kullanarak tekrarlanabilir olmasını istiyorsanız, güvensiz bir tohum hala faydalıdır.


Yaygın olmayan Matematik, internetten sadece tohumlama için veri indirir, rastgele sayılar üretirken bu rastgele verileri döndürmez.
Dan Dyer

SecureRandom ile aynı - / dev / urandom sadece tohumlama içindir.
AviD

Evet. Sorgulayan "Eğer rasgele bir sayı istiyorsanız SecureRandom kullanın - bu yavaş olabilir" dediğinde, belki her şey için getSeed kullanıyor ve entropi havuzunu boşaltıyor düşündüm. Düzeltme JDK 6'yı almak değil, SecureRandom'u amaçlandığı gibi kullanmaktır ;-)
Steve Jessop

@Dan Dyer - Yaygın olmayan Matematik hakkındaki yorumumu düzelttim. Sayfanıza bir göz attım, bu yüzden "rastgele sayılar" ile "tohum için" demek istediğimi biliyordum, "kullanıcıya geri dönmek". Ama tam olarak haklısın, söylediğim bu değil ...
Steve Jessop

"yaygın olarak kullanılabilir". Her uyumlu JDK'ya dahil değil mi? Java güvenlik standardı isimleri listesinde ... ( docs.oracle.com/javase/8/docs/technotes/guides/security/… )
Sean Reilly

176

Linux'ta daha hızlı ama biraz daha az güvenli / dev / urandom'u aşağıdakileri kullanarak seçebilmelisiniz:

-Djava.security.egd=file:/dev/urandom

Ancak, bu Java 5 ve üstü ile çalışmaz ( Java Bug 6202721 ). Önerilen çözüm aşağıdakileri kullanmaktır:

-Djava.security.egd=file:/dev/./urandom

(ekstralara dikkat edin /./)


24
Java Bug raporunda "Hata değil" yazdığını unutmayın. Başka bir deyişle, varsayılan olsa bile /dev/urandom, Sun buna sihirli bir dize olarak davranır ve /dev/randomyine de kullanır , bu yüzden sahte olmalısınız. file:URL ne zaman URL değildir file:? Sun'ın karar vermediğinde :-(
Jim Garrison

6
Sadece bu soruşturma zaman bir demet geçirmiş olması, hatta normal ayar görünüyor file:/dev/urandomsete -Djava.security.egdveya securerandom.sourcejava.security dosyasında, /dev/random/hala her okunduğunda SecureRandom.getSeed()(veya setSeed()adı verilir). file:/dev/./urandomSonuçların hiç okunmaması ile sonuçlanan geçici çözüm /dev/random(strace ile doğrulandı)
matt b

7
/dev/urandom/dev/randommodern bir CSPRNG ile uygulandığından daha az güvenli değildir : en.wikipedia.org/wiki//dev/random#FreeBSD
lapo

Bence asıl korku, /dev/urandom/oldukça öngörülebilir bir durumda olabilecek kutudan yeni donanımlar üzerinde sırlar üretmek için kullanırsanız ne olacağıdır. /dev/urandom/yapmanız gereken bir durum olmasına rağmen entropi için bloke olmaz. Gizli durum devam ederse, cihazınızın ilk önyüklemede yaptığı ilk şey bir genel-özel anahtar çifti oluşturmak gibi, durum daha da kötüdür. Bu korkutucu durumların dışında, bir iyilik /dev/urandom, ortak SecureRandomalgoritmaları kullanmaktan daha iyidir .
Steve Jessop

1
Hangisi doğru ? -Djava.security.egd = dosya: / dev /./ urandom veya dosya: /// dev / urandom @mattb
Aarish Ramesh

35

Linux'ta varsayılan uygulama SecureRandomIS NativePRNG(kaynak kodu burada eğilimi), çok yavaş olması. Windows'ta varsayılan değer SHA1PRNG, diğerlerinin de işaret ettiği gibi, açıkça belirttiyseniz Linux'ta da kullanabilirsiniz.

NativePRNGdan farklıdır SHA1PRNGve Uncommons Matematik AESCounterRNG (okuyarak sürekli işletim sisteminden entropi almasıdır /dev/urandom). Diğer PRNG'ler tohumlamadan sonra ek bir entropi elde etmezler.

AESCounterRNG, IIRC'nin SHA1PRNGkendisinden iki veya üç kat daha hızlı olandan yaklaşık 10 kat daha hızlıdır NativePRNG.

Başlatmadan sonra entropi alan daha hızlı bir PRNG'ye ihtiyacınız varsa, Fortuna'nın Java uygulamasını bulabileceğinizi görün . Bir Fortuna uygulamasının temel PRNG'si, AESCounterRNG tarafından kullanılanla aynıdır, ancak aynı zamanda entropi havuzu ve otomatik yeniden tohumlama için gelişmiş bir sistem de vardır.


Bu bağlantı çalışmıyor. uncommons-maths.dev.java.net/nonav/api/org/uncommons/maths/… . Bunu görebildiğim bir yer var mı?
UVM

@Unni Bağlantıyı yeni güncellediniz. Bu cevapta yaptığım performans iddialarının artık geçerli olmayabileceğini lütfen unutmayın. Sanırım Java'nın son sürümlerinde işler daha iyi olabilir ve platformlar arasında performans farklılıkları olabilir (Windows ve Liux gibi).
Dan Dyer

Ben sadece bir MessageDigest ile SecureRandom bir örnek çalıştırıyordu ve bir hexencoded yaptı. Windows 7 bilgisayarımdaki tüm işlem 33 milisaniye sürdü.Bir sorun. SHA1PRNG.SecureRandom prng = SecureRandom.getInstance ("SHA1PRNG"); String randomNum = new Integer (prng.nextInt ()) .toString (); MessageDigest sha = MessageDigest.getInstance ("SHA-1"); sonuç = sha.digest (randomNum.getBytes ()); str = hexEncode (sonuç);
UVM

24

Birçok Linux dağıtımı (çoğunlukla Debian tabanlı) OpenJDK'yı /dev/randomentropi için kullanacak şekilde yapılandırır .

/dev/random tanım gereği yavaştır (ve hatta engelleyebilir).

Buradan, engellemeyi nasıl kaldıracağınız konusunda iki seçeneğiniz vardır:

  1. Entropiyi iyileştirin veya
  2. Rasgelelik gereksinimlerini azaltın.

Seçenek 1, Entropiyi iyileştirin

Daha fazla entropi elde etmek için çirkin daemon'u /dev/randomdeneyin . HAVEGE entropisini sürekli olarak toplayan ve sanallaştırılmış bir ortamda çalışan bir daemon, çünkü herhangi bir özel donanım gerektirmiyor, sadece CPU'nun kendisi ve bir saat.

Ubuntu / Debian'da:

apt-get install haveged
update-rc.d haveged defaults
service haveged start

RHEL / CentOS'ta:

yum install haveged
systemctl enable haveged
systemctl start haveged

Seçenek 2. Rasgelelik gereksinimlerini azaltın

Herhangi bir nedenden ötürü yukarıdaki çözüm yardımcı olmazsa veya kriptografik olarak güçlü rasgeleliği umursamıyorsanız, /dev/urandombunun yerine geçmemeniz garanti edilen geçiş yapabilirsiniz .

Genel olarak bunu yapmak için, jre/lib/security/java.securityvarsayılan Java yüklemenizde kullanılacak dosyayı düzenleyin /dev/urandom(başka bir hata nedeniyle belirtilmesi gerekir /dev/./urandom).

Bunun gibi:

#securerandom.source=file:/dev/random
securerandom.source=file:/dev/./urandom

O zaman bunu komut satırında belirtmeniz gerekmez.


Not: Kriptografi yaparsanız, iyi bir entropiye ihtiyacınız vardır . Durumda - android PRNG sorunu Bitcoin cüzdanlarının güvenliğini azalttı.


Cevabınızı iptal ettiniz, ancak " /dev/randomtanımı gereği yavaştır (ve hatta engelleyebilir)" yanlış; tamamen sistem yapılandırmasına bağlıdır. Daha yeni makineler kullanılabilir CPU örn hızlı RNG olabilir ve BSD makineleri genellikle aynı uygulama var /dev/randomve /devl/urandom. Yine de, mutlaka hızlı olmaya güvenmemelisiniz /dev/random . VM'lerde, istemci VM'yi ana bilgisayar işletim sisteminin RNG'sini kullanabilmek için istemci VM'ye yüklemek isteyebilirsiniz.
Maarten Bodewes

17

SecureRandomBaşsız Debian sunucusunda bir seferde yaklaşık 25 saniye engelleme çağrıları ile benzer bir sorun vardı . havegedDaemon'u yukarıda tutmak için yükledim, /dev/randombaşsız sunucularda gerekli entropiyi oluşturmak için böyle bir şeye ihtiyacınız var. SecureRandomŞu anki çağrılarım belki milisaniye sürüyor.


4
apt-get install daha sonra güncelleme-rc.d varsayılanları var
Rod Lima

11

Gerçekten "kriptografik olarak güçlü" bir rastgelelik istiyorsanız, o zaman güçlü bir entropi kaynağına ihtiyacınız vardır. /dev/randomyavaştır çünkü sistem olaylarının entropiyi toplamasını beklemek zorundadır (disk okumaları, ağ paketleri, fare hareketi, tuşa basma vb.).

Daha hızlı bir çözüm, donanım rastgele bir sayı üretecidir. Anakartınızda yerleşik bir tane olabilir; Elinizde olup olmadığını ve nasıl kullanılacağını anlamak için hw_random belgelerine bakın. Rng-tools paketi, oluşturulan entropiyi içine besleyecek bir daemon içerir /dev/random.

Sisteminizde bir HRNG mevcut değilse ve performans için entropi gücünü feda etmek istiyorsanız, iyi bir PRNG'yi verileriyle tohumlamak /dev/randomve PRNG'nin işin büyük kısmını yapmasına izin vermek istersiniz . SP800-90'da listelenen ve uygulanması kolay olan birkaç NIST onaylı PRNG vardır.


İyi bir nokta, ama kodum ticari bir uygulamanın parçasıdır. Sunucu ortamı üzerinde herhangi bir denetimim yok. Hedef sunucuların her zaman fare ve klavyesiz olduğunu ve tamamen kök sorunu olan entropi için tamamen disk ve ağ G / Ç'ye güvendiğini düşünüyorum.
David G

3
/ Dev / random'ın sistem olaylarına bağlı olduğunu keşfettim, bu yüzden geçici bir çözüm olarak, testim devam ederken faremi ileri geri hareket ettirdim ....
David K

İ820 yongaseti için bu 82802 hub ağrılı yavaştı (RIP). Ondan yararlı bir şey toplayabileceğine şaşırdım. Bence sekizli toplamaktan ziyade bloke etmek için daha fazla zaman harcadım.
jww

6

Java 8 kullanarak, Linux çağrısında SecureRandom.getInstanceStrong()bana NativePRNGBlockingalgoritmayı vereceğini buldum . Bu, birkaç bayt tuz üretmek için genellikle birkaç saniye boyunca bloke olur.

Bunun NativePRNGNonBlockingyerine açıkça sormaya geçtim ve adından beklendiği gibi artık engellenmedi. Bunun güvenlikle ilgili etkilerinin ne olduğu hakkında hiçbir fikrim yok. Tahminen tıkanmayan versiyon kullanılan entropi miktarını garanti edemez.

Güncelleme : Tamam, bu mükemmel açıklamayı buldum .

Özetle, tıkanmayı önlemek için kullanın new SecureRandom(). Bu /dev/urandom, engellemeyen ve temelde güvenli olan kullanır /dev/random. Gönderiden: "/ dev / random'ı aramak istediğiniz tek şey, makinenin ilk kez başlatıldığı ve entropinin henüz birikmediği zamandır".

SecureRandom.getInstanceStrong() size en güçlü RNG'yi verir, ancak yalnızca bir grup engellemenin sizi etkilemeyeceği durumlarda kullanmak güvenlidir.


1
Sadece TLS sertifikaları gibi uzun vadeli anahtarlara izin veririm getInstanceStrong(). Ve o zaman bile new SecureRandom()FIPS uyumlu bir anahtar çifti üreteci veya rastgele sayı üreteci kullanmayı tercih ederim . Yani evet, bu, bir cevap sağlamaktadır eğer /dev/urandom engellemez: hala sonuçta sistem entropi dayanır sonunda; ama genel olarak çok iyi bir tavsiye . Eğer /dev/urandombloklar Eğer sorun değil de Java uygulamasının kaynağını düzeltmek gerekebilir.
Maarten Bodewes

5

Sisteminize yapay rastgeleliği besleyecek bir araç (en azından Ubuntu'da) var. Komut basitçe:

rngd -r /dev/urandom

ve önde bir sudo gerekebilir. Eğer rng-tools paketiniz yoksa, kurmanız gerekecektir. Bunu denedim ve kesinlikle bana yardımcı oldu!

Kaynak: matt vs world


2
Bu biraz tehlikelidir çünkü Linux çekirdeğinin entropi seviyesi tahminini sistem genelinde tamamen devre dışı bırakır. Bence /dev/./urandom kullanarak test amaçlı (okur: bir uygulamanın testsuite çalıştıran Jenkins) iyi, ama üretimde değil.
mirabilos

Bu benim için işe yarayan tek çözüm. Jenkins CI üzerinde Gradle ile bir Android projesi oluştururken "yeterli entropi" problemim vardı ve bir parametreyi derlemeye geçirmek yardımcı olmadı.
Slav

Ben xenial sudo rngd -r /dev/urandomile birleştirmek zorundasudo apt install rng-tools
MrMesees

5

Aynı sorunla karşılaştım . Doğru arama terimlerini içeren bazı Google'lardan sonra, DigitalOcean ile ilgili bu güzel makaleye rastladım .

haveged, güvenlikten ödün vermeden potansiyel bir çözümdür.

Sadece buradaki makaleden ilgili kısmı alıntılıyorum.

HAVEGE prensibine dayanarak ve daha önce ilişkili kütüphanesine dayanarak, bir işlemci üzerinde kod yürütme süresindeki değişikliklere dayanarak rastgele üretime izin verir. Bir kod parçasının aynı donanım üzerinde aynı ortamda bile aynı kesin zamanı yürütmesi neredeyse imkansız olduğundan, tek bir veya birden çok programı çalıştırma zamanlaması rasgele bir kaynak oluşturmak için uygun olmalıdır. Arızalı uygulama, bir döngüyü tekrar tekrar uyguladıktan sonra işlemcinizin zaman damgası sayacındaki (TSC) farklılıkları kullanarak sisteminizin rastgele kaynağını (genellikle / dev / random) tohumlar

Hasged nasıl kurulur

Bu makaledeki adımları izleyin. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Bunu gönderdiniz burada


5

Eğer başvurulan sorun hakkında /dev/randomsahip değildir SecureRandomalgoritma, ancak kullandığı rastgelelik kaynağı ile. İkisi dikeydir. İkisinden hangisinin sizi yavaşlattığını bulmalısınız.

Bağladığınız yaygın olmayan Matematik sayfasında, rastgele olma kaynağına değinmediklerinden bahsedilir.

Uygulamalarının SecureRandomdaha hızlı olup olmadığını görmek için BouncyCastle gibi farklı JCE sağlayıcılarını deneyebilirsiniz .

Kısa bir arama , Fortuna ile varsayılan uygulamanın yerini alan Linux yamaları da ortaya çıkarır. Bunun hakkında daha fazla bilgim yok, ama araştırmaya hazırsınız.

Ayrıca, kötü uygulanmış bir SecureRandomalgoritma ve / veya rasgelelik kaynağı kullanmak çok tehlikeli olsa da, kendi JCE Sağlayıcınızı özel bir uygulamayla yuvarlayabileceğinizi de belirtmeliyim SecureRandomSpi. Sunucunuzu imzalatmak için Sun ile bir süreçten geçmeniz gerekecek, ancak aslında oldukça basit; kripto kitaplıklarındaki ABD ihracat kısıtlamalarının farkında olduğunuzu belirten bir form fakslamanız yeterlidir.


Bu farklı JCE sağlayıcıları yalnızca başka bir entropi kaynağı kullanıyorlarsa kullanılırlar; bu da temel olarak HSM gibi belirli bir donanım parçası kullanmak zorunda oldukları anlamına gelir. Aksi takdirde, sistemden ne kadar entropi çıkardıklarına bağlı olarak yavaşlama yaşama olasılığı vardır.
Maarten Bodewes

3

Tekrarlayan bir algoritma için başlatma kaynağı olarak güvenli rastgele kullanın; o zaman UncommonMath yerine toplu iş için bir Mersenne twister kullanabilirsiniz, bir süredir var olan ve diğer prng'den daha iyi kanıtlanmış

http://en.wikipedia.org/wiki/Mersenne_twister

Şimdi yenilemeyi ve ardından başlatma için kullanılan güvenli rastgele yenilediğinizden emin olun, örneğin istemci başına bir mersenne twister sahte rastgele jeneratör kullanarak, istemci başına bir güvenli rastgele oluşturabilir ve yeterince yüksek bir randomizasyon elde edebilirsiniz.


2
Bu cevap yanlıştır: Mersenne kasırga değil , güvenli bir rasgele sayı üreteci. İçin iyi bir algoritma olurdu Random, ama değil SecureRandom.
Maarten Bodewes

3

Belgelere göre , SecureRandom tarafından kullanılan farklı algoritmalar tercih sırasına göre:

  • Çoğu * NIX sisteminde
    1. NativePRNG
    2. SHA1PRNG
    3. NativePRNGBlocking
    4. NativePRNGNonBlocking
  • Windows sistemlerinde
    1. SHA1PRNG
    2. Windows PRNG

Linux'u sorduğunuzdan, Windows uygulamasını ve ayrıca kendiniz yüklemediğiniz sürece sadece Solaris'te bulunan SunPKCS11'i görmezden geliyorum - ve sonra bunu sormazsınız.

Aynı belgelere göre, bu algoritmaların kullandığı

SHA1PRNG
İlk tohumlama şu anda sistem özellikleri ve java.security entropi toplama cihazı kombinasyonu ile yapılmaktadır.

NativePRNG
nextBytes() kullanır /dev/urandom
generateSeed()kullanır/dev/random

NativePRNGB kilitleme
nextBytes() ve generateSeed()kullanım/dev/random

NativePRNGNonBlokalama
nextBytes() ve generateSeed()kullanım/dev/urandom

Bu, kullanırsanız SecureRandom random = new SecureRandom(), genellikle NativePRNG olan bir tane bulana kadar bu listeye iner. Ve bu, kendisini tohumladığı /dev/random(veya açıkça bir tohum oluşturursanız kullanır), daha sonra bir /dev/urandomsonraki bayt, ints, double, booleans, neyin var olduğunu almak için kullanır .

Yana /dev/random(o entropi havuzunda yeterli entropi belli olmadan blokları) engelliyor, bu performansı engelleyebilir.

Bunun bir çözümü yeterli entropi üretmek için bir şey kullanmaktır, /dev/urandombunun yerine başka bir çözüm kullanmaktır . Bunu tüm jvm için ayarlayabilirsiniz, ancak daha iyi bir çözüm SecureRandomkullanarak bu özel örneği için yapıyor SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking"). NativePRNGNonBlocking varsa bu yöntemin bir NoSuchAlgorithmException özel durumu atabileceğini unutmayın, bu nedenle varsayılana geri dönmeye hazır olun.

SecureRandom random;
try {
    random = SecureRandom.getInstance("NativePRNGNonBlocking");
} catch (NoSuchAlgorithmException nsae) {
    random = new SecureRandom();
}

Ayrıca diğer * nix sistemlerde /dev/urandomfarklı davranabileceğini unutmayın .


/dev/urandomrastgele yeter?

Geleneksel bilgelik, sadece /dev/randomyeterince rasgele. Ancak, bazı sesler farklıdır. In "Kullanım SecureRandom Hakkı Yolu" ve "/ dev / urandom hakkındaki mitler" , o kadar ileri sürülmektedir /dev/urandom/sadece iyi gibidir.

Bilgi Güvenliği yığınındaki kullanıcılar bunu kabul eder . Temel olarak, sormanız gerekiyorsa, /dev/urandomamacınız için iyidir.


2

Bu soruna kendim çarpmadım, ama program başlangıcında hemen bir tohum üretmeye çalışan bir iplik doğurdum, sonra öldü. Rastgele için çağırdığınız yöntem, canlıysa bu iş parçacığına katılır, böylece ilk çağrı yalnızca programın yürütülmesinde çok erken gerçekleşirse engellenir.


Oldukça aşırı bir saldırı, ama işe yarayabilir; kullanılan PRNG'nin hala blokaja yol açabilecek ek tohum malzemesi kullanamayacağı söylenmez. Entropiyi sisteme sağlayan veya sabitleyen farklı bir rasgele sayı kullanılması kuvvetle tercih edilmelidir. En azından geçici bir çözüm sunabileceğinden, cevabı daha az oyladım.
Maarten Bodewes

2

Deneyimlerim, PRNG'nin yavaş yavaş başlatılmasıyla oldu, bundan sonra rastgele veri üretimi ile değil. Daha istekli bir başlatma stratejisi deneyin. Oluşturmaları pahalı olduğu için, tek birton gibi davranın ve aynı örneği tekrar kullanın. Bir örnek için çok fazla iş parçacığı çekişmesi varsa, bunları havuzlayın veya iş parçacığı yerel yapın.

Rastgele sayı üretmekten ödün vermeyin. Orada bir zayıflık tüm güvenliğinizi tehlikeye atar.

Çok fazla COTS atomik bozunma tabanlı jeneratör görmüyorum, ancak gerçekten çok fazla rastgele veriye ihtiyacınız varsa, onlar için birkaç plan var. HotBits de dahil olmak üzere her zaman ilginç şeyler olan bir site, John Walker'ın Fourmilab'ı.


1
Bunu hep merak ettim, çünkü hadronic tau bozunma ürünleri neredeyse rastgele bir kaynak idealine ulaştığından, algoritmik araçlar yerine bunu kullanma isteğimden kurtulamıyorum. Op'un amacı için, uzun zaman önce bazı ön uç zamanının tüm güvenli araçlara endemik olduğuna karar verdim. Biri bir kurucuya ihtiyaç duyacaksa, bu yapıcıda çağrılabilir ve sadece sayfa yükleme zamanında bir tane oluşturmayı hatırlarsa, avl takasının altına gömülür ve benim olduğum kadar seçici olur.
Nicholas Jordan

Intel 8xx yonga setlerinde (ve muhtemelen diğerlerinde) termal gürültü kullanan, gerçekten öngörülemeyen bir kuantum etkisi olan bir donanım RNG'si vardır. Güvenilir Platform Modülleri donanım RNG'leri de içerebilir, ancak maalesef dizüstü bilgisayarımdakiler içermiyor.
erickson

Bir kez tohumlanırsa veya bir süre sonra yeniden tohumlanırsa belirli RNG'ye bağlıdır. NIST, yeniden satış yapan PRNG'leri belirtir, ancak birçok yazılım uygulaması belirtmez. Kodun tek birton etrafında yeniden yapılandırılması, özellikle çok iş parçacıklı uygulamalarda korkunç bir fikirdir; sorunun kaynağını düzeltmek daha iyidir: entropi eksikliği nedeniyle yavaş tohumlama. Tek birton kullanıyorsanız, bunu tamamen belirleyici olan diğer SecureRandom uygulamaları için tohumlar sağlamak üzere kullanın. Bu tür bir tasarım muhtemelen biraz bilgi gerektirir.
Maarten Bodewes

@MaartenBodewes Bunlar iyi puanlar. Uygulama, sistem entropisini bekleyerek engelleyen bir uygulama ise, altta yatan kaynağın etkili bir şekilde bir singleton olması nedeniyle, uygulamanızda tekil olarak ele alınmasının korkunç bir fikir olmadığını düşünüyorum. Ancak bu örneği başkalarını tohumlamak için kullanmak karmaşık olsa bile iyi bir öneri. Emin değilim, ama Güneş (ve sonra Oracle) sağlayıcısının SecureRandomentropi toplantısında son 10 yılda birkaç kez değiştiğini düşünüyorum .
erickson

Ben birkaç kez değişti eminim, o kadar ki ben bu yorumu tüm değişiklikleri koymak ve denemek olmaz :). Yavaşlığın SecureRandomhala bir sorun olması daha az olasıdır , ancak sistemdeki düşük entropi her zaman sorun olacaktır. Tek birtonun kullanılması, bir tasarım anti-paterni olan güçlü bir şekilde birleştirilmiş kod oluşturacaktır. Bu nedenle çok dikkatli kullanılmalıdır; sorunu giderirseniz, tercihen koddaki tüm referansları tersine çevirmeniz gerekir.
Maarten Bodewes

2

RNG gereksinimleriniz hakkında daha net olmanız gerektiği anlaşılıyor. En güçlü kriptografik RNG gereksinimi (anladığım kadarıyla), bunları oluşturmak için kullanılan algoritmayı bilseniz ve daha önce oluşturulan tüm rasgele sayıları bilseniz bile, üretilen rasgele sayılar hakkında herhangi bir yararlı bilgi alamazsınız. Gelecekte, pratik olmayan bir hesaplama gücü harcamadan.

Bu tam bir rastgelelik garantisine ihtiyacınız yoksa, muhtemelen uygun performans ödünçleri vardır. Dan Dyer'in Uncommons-Maths veya Fortuna'dan AESCounterRNG hakkındaki cevabına katılıyorum (yazarlarından biri kriptografi uzmanı Bruce Schneier). Ben de hiç kullanmadım ama fikirler ilk bakışta saygın görünüyor.

Ben olacağını düşünüyorum periyodik bir başlangıç rastgele tohum üretmek eğer o (örn kez gün veya saatte ya da her neyse başına), sen akış şifresi tam o sırada XOR kullanıyorsa (akışının ardışık parçalar rastgele sayılar oluşturmak için hızlı kesintisiz şifrelemeyi kullanabilirsiniz null akışından geçirin veya doğrudan XOR bitlerini alın). ECRYPT eStreamproje performans kriterleri de dahil olmak üzere birçok iyi bilgiye sahiptir. Bu, doldurduğunuz zamanlar arasındaki entropiyi sürdürmez, bu nedenle birisi rasgele sayılardan ve kullandığınız algoritmadan birini biliyorsa, teknik olarak, çok sayıda hesaplama gücüyle, akış şifresini kırmak ve gelecekteki rasgele sayıları tahmin edebilmek için iç durumunu tahmin edebilir. Ancak, bu riskin ve sonuçlarının entropiyi sürdürmenin maliyetini haklı çıkarmak için yeterli olup olmadığına karar vermelisiniz.

Düzenleme: İşte bu konuda çok net görünüyor net 'buldum RNG bazı kriptografik ders notları .


1
"Fortuna (yazarlarından biri kriptografi uzmanı Bruce Schneier)" - diğeri ise kriptografi uzmanı Niels Ferguson :-)
Steve Jessop

2

Donanımınız destekliyorsa , yazarı olduğum Java RdRand Yardımcı Programını kullanmayı deneyin .

Intel'in RDRANDtalimatlarına dayanır SecureRandomve büyük hacimli uygulamalardan yaklaşık 10 kat daha hızlıdır ve bant genişliği sorunları yoktur.


Bu uygulamanın yalnızca talimat sağlayan CPU'larda (yani rdrandişlemci bayrağı ayarlandığında) çalıştığını unutmayın . RdRandRandom()Yapıcı aracılığıyla açıkça başlatmanız gerekir ; spesifik bir Provideruygulama yapılmamıştır .


3
People.umass.edu/gbecker/BeckerChes13.pdf dosyasını okumak ve yalnızca Intel RDRAND verilerini asla kullanmadığınızdan emin olmak isteyebilirsiniz. Her zaman bir aRC4 akış şifresinin çıkışı (/ dev / urandom'dan ekilen ve bilinen önyargıları için atılan ilk birkaç KiB değeri) gibi öngörülemeyen verilerle karıştırın.
mirabilos

+1 mirabilos. Bence RDRANDiyi bir kaynak, ama biraz güvenilmez. Kesinlikle bir koleksiyoncuya çok sayıda girdi olması gerekiyor (David Johnston'a suç yok).
jww

Oy verdim, bağlantıyı düzelttim ve bazı arka plan bilgileri sağladım. Kabul etmiyorsanız lütfen düzenlemeyi geri alın.
Maarten Bodewes

1

Bakmak için başka bir şey lib / security / java.security dosyasındaki securerandom.source özelliğidir

/ Dev / random yerine / dev / urandom kullanmanın bir performans avantajı olabilir. Rastgele sayıların kalitesi önemliyse, güvenliği bozan bir taviz vermeyin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.