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

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?

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.

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 /./)

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.

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ı.

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.

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.

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.

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

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

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.

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.

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 .

Mı /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.

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.

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'ı.

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ı .

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 .

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.