Lava Lambalarının İşe Yaramazlığı: Rastgelelik Gerçekte Ne Anlama Gelir

• Cloudflare’ın lava lambasına dayalı rastgele sayı tanıtımı, internet şifrelemesine büyük ve pratik bir katkı sağlamaktan çok pazarlama ve güvenlik tiyatrosuna benziyor
• Kriptografide önemli olan, bir değerin özünde rastgele olmasından çok, saldırganın o değer hakkında ne kadar bilgi sahibi olduğu; güvenliği belirleyen de bu bilgi farkıdır
• One-time pad, yeterince rastgele bir anahtar yalnızca bir kez kullanıldığında düz metin bilgisini gizler; ancak aynı anahtar yeniden kullanılırsa gözlemlenen bilgiyle birleşerek kırılır
• Modern sistemler one-time pad yerine CSPRNG ve akış şifreleri kullanır; ChaCha20 veya AES-256-CTR, 256 bit anahtarla pratik güvenlik sağlar
• Fiziksel true RNG’lerde önyargıyı gidermek zordur ve güvenlik artışı da küçüktür; bu yüzden sunucunun tohumu doğrudan üretip fast key erasure kullanması daha basit ve daha güvenlidir

---

Rastgelelik, nesneden çok gözlemcinin bilgisine bağlıdır

• Cloudflare, lava lamp'lerin internet şifrelemesine yardımcı olduğunu tanıtıyor; ancak bu yaklaşım, güvenliğe büyük katkı sağlamaktan çok pazarlama ve güvenlik tiyatrosuna benziyor
• Cloudflare, lava lambalarının yanı sıra double pendulums, wave motion, mobiles gibi fiziksel öngörülemezlik düzenekleri de kullanıyor
• Yalnızca return 4 yapan XKCD tarzı fonksiyon, her zaman 4 döndürdüğü için nesnenin kendisi açısından rastgele değildir; ancak çağıran taraf yalnızca “adil bir zarla seçilmiş sabit” bilgisini biliyor ve onu bir kez çağırdıysa, gözlemcinin olasılık dağılımında rastgele muamelesi görebilir
• Kriptografide asıl soru, sonucun özünde rastgele olup olmadığı değil, saldırganın o sonuç hakkında ne kadar bildiğidir
• Aynı değer bile, kimin hangi bilgiye sahip olduğuna göre farklı bir rastgelelik anlamı taşır; kriptografik sistemlerde güvenliği belirleyen de bu bilgi farkıdır

One-time pad nasıl çalışır ve nasıl kırılır

• Russian roulette benzetmesinde suç ortağı, merminin konumunu bilir ve oyuncuyla önceden paylaşılan zar değerini mermi konumuna ekledikten sonra yalnızca sonucu dışarıya söyler
• Oyuncu, söylenen değerden zar değerini çıkararak mermi konumunu yeniden elde edebilir; fakat karşı taraf zar değerini bilmediği için yalnızca söylenen sayıdan mermi konumunu öğrenemez
• Zar adilse, karşı tarafın sahip olduğu önsel olasılık P(Ci) ile belirli bir S3 duyduktan sonraki artgönderim olasılığı P(Ci|S3) aynı olur
• Bayes formülünde P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci) olur; yani karşı taraf söylenen değeri duysa bile hiçbir bilgi öğrenmez
• Bu yapı, One-time pad'in özüdür; yeterince rastgele bir anahtar mesajla yalnızca bir kez birleştirilirse şifreli metin, düz metin hakkında bilgi açığa çıkarmaz
• Aynı anahtar ikinci oyunda yeniden kullanılırsa, ilk oyunda açığa çıkan bilgi nedeniyle karşı taraf zar değerinin olası aralığını daraltabilir
• İlk oyunda silahın ön dört yuvasının boş olduğu anlaşılırsa, karşı taraf zarın yalnızca 3 ya da 4 gelmiş olabileceğini bilir; ardından suç ortağı ikinci kez “Four” derse, merminin ya ilk yuvada ya da son yuvada olduğu bilgisini de elde eder
• One-time pad, adından da anlaşılacağı gibi yalnızca bir kez güvenlidir; aynı anahtar yeniden kullanıldığında gözlemlenen şifreli metinler ve önceki bilgiler birleşerek güvenliği çökertir

Anahtar uzunluğu ve modern şifrelemenin pratik güvenliği

• İnternette mermi konumu yerine bitler ve baytlar gönderilir; tek bitlik bir “yes/no” mesajı tek bir yazı tura atışıyla gizlenebilir
• Tura gelirse mesaj olduğu gibi bırakılır, yazı gelirse “yes” ile “no” yer değiştirir; para sonucunu bilmeyen gözlemci için bu, düz metni gizler
• Ancak aynı para sonucu iki biti şifrelemek için kullanılırsa, şifreli metin dört olası düz metni iki olasılığa indirger
  • “Yes yes”, düz metnin “yes yes” ya da “no no” olduğu anlamına gelir
  • “No no”, düz metnin “no no” ya da “yes yes” olduğu anlamına gelir
  • “Yes no”, düz metnin “yes no” ya da “no yes” olduğu anlamına gelir
  • “No yes”, düz metnin “no yes” ya da “yes no” olduğu anlamına gelir
• Genelleştirirsek, n biti tek bir yazı tura atışıyla şifrelediğinizde olası düz metin uzayı 2^n'den 2 seçeneğe iner
• Tam bilgi kuramsal anlamda n biti düzgün şekilde şifrelemek için n bit anahtar gerekir; bundan daha uzun mesajlarda bir kısmı çözülebilir ve gözlemci zaten n bitten fazla bilgi biliyorsa, çoğunlukla mesajın tamamı çözülebilir
• Cloudflare’ın işlediği tüm trafiğe one-time pad uygulamak astronomik miktarda rastgele sayı gerektiriyor gibi görünse de modern sistemler one-time pad kullanmaz
• Kimlik doğrulamalı şifreleme ve akış şifreleri doğru kullanıldığında, 256 bit anahtarla büyük miktarda veri pratik olarak güvenli biçimde şifrelenebilir
• ChaCha20 veya AES-256-CTR gibi uygun bir akış şifresi kullanıldığında, pasif bir gözlemcinin düz metni bulmak için yaklaşık 2^255 kombinasyon denemesi gerekir
• Anahtarı bilen biri için akış tamamen öngörülebilirdir; ancak anahtarı bilmeyen, Dünya uygarlığı ölçeğindeki bir gözlemci için tamamen öngörülemez bir “entropi” gibi davranır
• Bunun resmî adı Cryptographically Secure Pseudo-Random Number Generator, kısaca CSPRNG'dir

Gerçek rastgele sayı üretimi ve fast key erasure

• Gerekli rastgele sayıları tek bir 256 bitlik ana anahtardan türetmek için, ana anahtar bir ana sunucuda veya donanım güvenlik modülünde tutulabilir; yerel anahtar akışları üretilip şirket geneline güvenli biçimde dağıtılabilir
• Her sunucu veya CPU çekirdeği, 256 bitlik bir yerel anahtar ve sayaçla ihtiyaç duyduğu kadar rastgele bayt üretebilir
• Buradaki temel sorun, güvenli dağıtımın son derece zor olmasıdır
• Yerel anahtar sızarsa, ilgili makinenin geçmişte şifrelediği tüm mesajlar ve gelecekte şifreleyeceği mesajlar risk altına girer; ana anahtar sızarsa zarar çok daha büyük olur
• fast key erasure, anahtar sızıntısı olasılığını ve sızıntı gerçekleştiğinde oluşacak zararı azaltmaya yönelik bir prosedürdür
  • 512 baytlık bir tamponun başına 32 baytlık rastgele bir tohum yerleştirilir
  • Bu tohumla 512 bayt üretilir ve tampon bununla üzerine yazılır
  • İlk 32 bayt dışındaki kısım istek geldikçe çıktı olarak verilir ve ardından silinir
  • Tampon bitince yeniden üretim aşamasına dönülür
• “erasure” adı, üretim aşamasının mevcut anahtarı silip yerine yenisini koymasından gelir
• Tampon sızarsa gelecekteki mesajlar riske girebilir, ancak daha önce çıktı olarak verilmiş ve silinmiş geçmiş değerler korunur
• Daha da önemli uyarı, tamponun kopyalanmamasıdır
  • Aynı tohumdan iki akış üretilmemelidir
  • Süreç fork edildiğinde akış uygun şekilde ikiye ayrılmalıdır
• Aynı akıştan birden fazla kopya oluşursa, aynı rastgele baytlar tekrar eder ve bu ölümcül olabilir
• Bu nedenle kullanıcı alanı RNG’leri tavsiye edilmez; çekirdek RNG’si kolay olmasa da denetlenmesi gereken bileşen sayısını azaltır

Akış şifresi seçimi ve güvenlik payı

• Temel alınan akış şifresinin iç blok boyutu da önemlidir
• ChaCha20'nin 512 bitlik bloğu kaygılanmayı gerektirmeyecek kadar büyüktür; AES'in 128 bitlik bloğu da yeterince büyüktür
• AES’e karşı, basit brute force’a göre başarı olasılığı çok daha yüksek gerçek saldırılar vardır; AES-128 kırılabilir kabul edilirken AES-256 güvenli sayılır
• Daha küçük blok boyutları bu kullanım için kırılmış kabul edilmelidir
• Önerilen seçenekler ChaCha20 veya AES-256’dır; tercih ChaCha20 yönündedir
• Modern akış şifreleri son derece güvenlidir; akademik literatür ve çeşitli hükümetlerin, özellikle de ABD’nin kullanım örnekleri dikkate alındığında, yakın gelecekte kırılma olasılıkları çok düşüktür
• Hem CSPRNG hem de şifreleme kriptografiye dayandığından, bunlardan biri kırılırsa tüm sistem de kırılır
• AES-256 veya ChaCha20’nin yakın gelecekte anlamlı biçimde kırılabileceğini varsayarsanız, güvenlik payını artırmak için bazı seçenekler vardır
  • CSPRNG ve şifreleme için aynı şifreyi kullanmak, saldırganın AES ya da ChaCha’dan sadece birini kırmasının yeterli olduğu bir seçeneği ortadan kaldırır ve onu tek bir belirli şifreyi kırmaya zorlar
  • Tur sayısını artırmak, yalnızca brute force maliyetini değil, brute force’tan daha iyi saldırılara karşı direnci de artırır
  • AES-256 14 tur, ChaCha20 ise 20 tur kullanır
  • ChaCha7 için exhaustive search’ten daha iyi saldırılar vardır, ancak ChaCha8 için şu anda böyle bir saldırı bilinmemektedir
  • ChaCha20, aniden 12 turlu bir saldırı keşfedilse bile sorun çıkmaması için 20 tur kullanarak güvenlik payı bırakır
• Birden fazla sistemi paralel kullanmak toplam karmaşıklığı ciddi biçimde artırır ve bu karmaşıklık, bileşenlerden birine yönelik matematiksel saldırıdan daha ölümcül zafiyetler üretme eğilimindedir

Fiziksel true RNG ve ilk tohum

• Fiziksel true RNG’lerin, teorik olarak kırılabilir CSPRNG’lerden daha güvenli olduğu düşüncesine temkinli yaklaşmak gerekir
• Güvenlik için rastgele çıktının çoğu durumda tespit edilebilir bir önyargı taşımaması gerekir; bu da 2^64 örnek analiz edilse bile önyargının fark edilemeyeceği kadar düzgün bir dağılım anlamına gelir
• Fiziksel süreçleri bu düzeye ayarlamak zor olduğu için, pratikte gürültü kaynağının çıktısını kriptografik bir hash’ten geçirmek gerekir
• Fast key erasure kullanan bir akış şifresiyle karşılaştırıldığında güvenlik artışı küçüktür; buna karşılık performans maliyeti duruma göre yüksek olabilir
• Rastgele sayıların keyfî miktarda üretilebilmesi için başlangıçta birkaç baytlık bir tohum gerekir
• Öngörülemez bir kaynak yeterince uzun süre dijital olarak kaydedilip 256 bitten fazla entropi elde edildikten sonra, bu kayıt SHA-256 veya BLAKE2s gibi 256 bitlik bir hash ile hash’lenerek ana tohum üretilebilir
• Olası rastgelelik kaynakları arasında hardware random number generator, CPU jitter, rastgele ağaç fotoğrafları, beam splitter, tuş vuruşları veya fare olayları, zarlar gibi kaynaklar bulunur
• Siteler arasında rastgele sayı dağıtımı pratik değildir; yalnızca karmaşık olmakla kalmaz, aynı zamanda ihlal nedeni de olabilir
• Rastgele sayılara yalnızca bir kez değil, ihlal şüphesi doğduğunda veya önemli güvenlik güncellemeleri yapıldığında da ihtiyaç vardır
• Uğraşı ve riski azaltmak için, dışarıdan getirmek yerine ilgili bilgisayarın kullanacağı rastgele tohumu kendisinin üretmesi genellikle daha iyidir
• Tipik sunucularda CPU jitter, çevre birimi etkileşimleri ve ağ olayları bulunduğundan, bunlar çoğu kullanım için yeterlidir
• Ek güvenlik istenirse her sunucu rafına birkaç donanım RNG dongle’ı eklenebilir; ancak bundan daha karmaşık yaklaşımlar gereksiz karmaşıklık yaratır

Lava lambası duvarı neden gereksiz

• Cloudflare’ın lava lambası duvarına ihtiyacı yoktur; bunu yerel ağ üzerinden sunuculara bağlamak yalnızca ek karmaşıklık ve saldırı yüzeyi yaratır
• Doğru uygulanırsa risk çok düşük olabilir, ancak yine de sağladığı faydadan daha büyük bir risk taşır
• Cloudflare güvenliği gerçekten ciddiye alıyorsa, lava lambalarını kullanmayı bırakmalı ve onları yalnızca dekorasyon ve pazarlama amacıyla tutmalıdır
• Sunucuların rastgele sayıları her birinin doğrudan kendisinin üretmesi daha basit ve daha güvenlidir
• Cloudflare’ın zaten böyle yapıyor olması da mümkündür

[GN⁺]

Lobste.rs görüşleri

• Bu yazı hem yanlış bilgilerle yazılmış gibi görünüyor hem de biraz heves kaçırıcı. Modern rastgele sayı üretimi, birden fazla bağımsız entropi kaynağı kullanır ve bilgisayar çalışırken bunları sürekli entropi havuzuna hash’leyerek karıştırır.
  Bilgisayarda tek bir “rastgele tohum” yoktur; bunun yerine çalışma sırasında seed = hash(seed, new_data) gibi bir yöntemle çeşitli kaynaklardan gelen entropiyle sürekli yeniden tohumlanır. Lav lambalarını çeken bir kameradan veri eklemek sistem güvenliğini asla düşürmez. Entropi havuzuna giren veri, zaten içerde olan diğer verilerle birlikte hash’lenir. Tasarım, saldırganın bilmediği çok az miktarda bilgi bile varsa güvenli kalacak şekilde yapılmıştır; bu yüzden rastgelelik kalitesi farklı çok sayıda veriyi karıştırmak güvenliği bozmaz.
  Lav lambaları sistem güvenliğine zarar vermez; bence ayrıca sistemin bir parçası olan keyifli ve işlevsel bir sanat eseri sayılır. Rastgele sayı kalitesini de son derece küçük bir miktarda artırır ve rastgelelik ile entropi kavramlarını görsel olarak gösterir.

  • Doğru, ama çekirdek rastgele sayı üreteçleri zaten 30 yılı aşkın süredir çeşitli donanım rastgeleliği kullanıyor ve ne kadar “sürekli” ya da “durmaksızın” yeniden tohumlandığı konusunda abartıya kaçmamak gerekir.
    Donanımdan rastgelelik sürekli toplanır, ancak Linux rastgele sayı üreteci periyodik olarak yeniden tohumlanır. Açılıştan sonraki ilk 1 dakika boyunca birkaç saniyede bir, sonrasında ise yaklaşık dakikada bir olacak şekilde yavaşlar.

    https://zx2c4.com/projects/linux-rng-5.17-5.18/…

  • Mevcut sistemlerin böyle olmadığını söylediğim ya da ima ettiğim izlenimini nereden verdiğimi bilmiyorum. Burada, lav lambası kısmı dışında, mevcut sistemleri açıklamaya çalışmıyordum; aslında ihtiyaç duyduğumuz şeyin ne kadar az olduğunu, yani 256 bitin yeterli olduğunu vurgulamak istiyordum.
    Lav lambalarını çeken bir kameradan veri eklemenin güvenliği azaltmayacağı sözü bana saldırı yüzeyini düşündürüyor. Sonuçta gömülü bir bilgisayar ve o bilgisayarla sunucu arasındaki ağ iletişimini ekliyorsunuz. Bana göre bunun getirdiği küçük risk bile, gerçekten lav lambasına ihtiyaç duyulacak kadar saçma derecede düşük bir riskten çok daha büyük görünüyor.

• Felsefi ayrımı farklı ifade edecek olursak şöyle: kaç tane olası sonuç var ve sonuç ne kadar öngörülebilir?
  Kriptografik amaçlar için öngörülebilirliği 2^-256 düzeyine oturttuk, ama ilginç olan şu ki olası sonuç sayısı çok daha büyük olan yaygın süreçler de var ve bazen olasılığı ne kadar düşük olursa olsun her olası sonucu üretebilmek istersiniz. Böyle durumlarda kriptografik rastgelelik yetersiz kalabilir.
  Standart bir deste kartta 52! farklı karışım vardır; bu yaklaşık 2^226 eder, yani kriptografik olarak rastgele bir tohumla tüm karışımlar üretilebilir. Ama Uno oynarsanız ya da birden fazla desteyi birlikte karıştırırsanız, 256 bitlik bir rastgele sayı üretecinin tüm karışımları üretecek kadar durumu kalmaz. Sistemdeki kullanıcı alanı rastgeleliğinin tamamı çekirdekten geliyorsa ve çekirdek tüm donanım rastgeleliğini 256 bitlik bir CSPRNG’den geçiriyorsa, Las Vegas’ta kart karıştırmak için yeterli olmayabilir :-)
  Yazıda eksik kalan şey yeniden tohumlama; hızlı anahtar silmeyle nasıl etkileştiğini ve ilk tohumu edinmenin zorluğunu göstermesi açısından ilginç bir konu. Yazı, Linux’un yalnızca CPU jitter kullandığını ima ediyor ama bu aşırı bir sadeleştirme. Linux birçok rastgelelik kaynağı kullanır ve jitter dansını yalnızca son çare olarak uygular.

  • Hayır, gerçek hayatta asla böyle yapılmaz.
    Gerçek dünyada 2^128 örnek bile asla elde edilemez. Hatta bunun çok daha azı elde edilir; bu yüzden AES-128 hâlâ birçok kullanım için yeterince güvenlidir. Olası sonuç sayısı 2^256’dan büyük olduğunda “bütün olası sonuçları üretmek” tamamen imkansızdır. Bunu unutmak daha iyi; böyle bir şey yoktur.
    Blackjack’te tek deste yerine 6 deste kullanıldığında bile, aslında tüm olası karışımlar üzerinde olasılığı eşit dağıtan bir karıştırma süreci istenmez. Yeterince iyi bir dağılım olması yeterlidir; yani mümkün olduğunca çok örnek alsanız bile farkı ayırt edemeyeceğiniz kadar iyi olması. Karışım sayısı 2^256, hatta 2^128 ile sınırlı olsa bile farkı anlayamazsınız.
    Yazıda yeniden tohumlamayı çıkarmam kasıtlıydı. Buna yalnızca şüpheli ihlaller ve bazı güvenlik güncellemeleri gibi belirli anlarda ihtiyaç vardır. Rastgele sayı üreteci durumunu kalıcı bellekte tutmaktan daha basit ya da daha güvenliyse yeniden başlatmalarda da geçerlidir. Bu yüzden buna “yeniden tohumlama” demektense yeni bir ilk tohumla yeniden başlamak demeyi tercih ediyorum.
    Normal çalışma sırasında yeniden tohumlamaya hiç gerek yoktur. Uygulamaya kalkınca sadece karmaşıklık ekler.
    Linux’un yalnızca CPU jitter kullandığı imasını doğrulamam gerekirdi. Benim anladığım kadarıyla önyükleme anında tek kaynak oydu. Özellikle kullanıcı girdisi ve ağ girdisi gelmeden önce böyle olduğunu düşünüyordum. Bildiğiniz başka kaynaklar var mı? Donanım rastgele sayı üreteci desteği zaten olmalı gibi görünüyor.
  • Olasılık ile öngörülebilirlik ayrımını görünce Shamir, Rivest, Adleman makalesi aklıma geldi. Bu makale, iki kişinin telefonda sanal bir kart destesi kullanarak güvenli poker oynamasının matematiksel olarak imkansız olduğunu kanıtlıyor.
    Yapılamaz. Ama bunu bir kenara bırakırsak, güvenli şekilde yapmanın yolu şu…
  • İlginç. Doğru hatırlıyorsam gerçek rastgele kaynaklardan okumak bloklayan bir işlemdir; yani çekirdekte yeterli rastgele bayt yoksa, yeterli rastgelelik okunana kadar oldukça uzun süre beklenebilir.
    Tahminimce rastgele sayı üreten donanım kartları, yalnızca bit yoğunluğu için değil, birim zaman başına bit sayısıyla da ölçülen paralel rastgelelik kaynakları elde etmek için vardı.

• Tek tek iddiaların çoğuna güçlü biçimde karşı çıkmıyorum ama genel argüman bana bulanık geldi. Yazı “modern kripto insanların düşündüğünden çok daha az gerçek rastgelelik gerektirir” fikrinin etrafında kuruluyor, sonra da “o halde lav lambaları saldırı yüzeyini genişlettiği için daha kötüdür” sonucuna varıyor.
  İki iddia da doğru olabilir ama sonuca giden akış biraz kaba duruyor.

  • Dürüst olmak gerekirse anlatı yapısı çok tatmin edici değil. Yine de sonucun yarısını başlığa zaten yazmıştım.

• LavaRand bunu 20 yıldan uzun süre önce zaten yapıyordu. O zamanlar sevimliydi ama o dönemin kamera sensörleri çok daha küçüktü ve lens gibi öngörülebilir özellikler yüzünden entropi kaynağı olarak pek iyi değildi.
  Lav lambalarını sevsem de, yüzlercesinden oluşan bir duvarın güç tüketimi oyuncak sayılabilecek bir düzenek için epey yüksek.

• Kendini tanıtmaya oldukça yakın. Neredeyse hiç bağlantı paylaşmıyor; paylaştığında da kendi bağlantılarını paylaşıyor. Son 5 gönderisinin 5’i de kendi materyallerine işaret ediyor.

  • Bu, “stories and comments” ifadesini nasıl yorumladığınıza bağlı.
    “Yazarın topluluğa katılması iyidir, ancak bunu ürün duyuruları veya kendi çalışmalarına trafik çekmek için tek yönlü bir araç olarak kötüye kullanmamalıdır. Kaba kural olarak öz tanıtım, kişinin kendi stories ve comments toplamının dörtte birinden az olmalıdır.”
    15 gönderi ve 1399 yorum varsa, topluluğa açıkça katılım var demektir. Tabii kendi gönderilerinin her birine 90’dan fazla kendi yorumu düşmüyorsa.

• Cloudflare, lav lambalarından elde edilen entropiyi; University of Chile deprem verilerini; doğru hatırlıyorsam EPFL ise radyoaktif bozunma ölçümlerini; ayrıca çeşitli başka katılımcılar da farklı verileri drand ağının ilk anahtar üretim törenine katkı olarak sundu.
  CSPRNG kullanılabilir miydi? Elbette. Ama o zaman eğlencesi nerede?

  • Eğlence güzel. Lav lambaları hoş görünüyor ve onların dalga duvarı gerçekten çok güzel. Çizginin aşıldığı nokta, bunun gerçekten güvenliğe yardımcı oluyormuş gibi davranması.