I2P Geliştirici Toplantısı - 07 Şubat 2006

15:36 <jrandom> 0) merhaba 15:36 <jrandom> 1) Ağ durumu 15:36 <jrandom> 2) _PRE net ilerlemesi 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) merhaba 15:37 * jrandom el sallar 15:37 <jrandom> haftalık durum notları şurada yayınlandı: http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> merhaba 15:38 <jrandom> sizler o pek heyecan verici materyali didiklerken, hadi 1) Ağ durumu ile dalalım 15:38 <jrandom> son hafta içinde, I2P açısından, canlı ağda pek bir değişiklik olmadı, o yüzden burada ekleyecek çok bir şeyim yok 15:39 <jrandom> mevcut ağ durumu hakkında gündeme getirmek istediğiniz bir şey var mı? 15:39 <KBlup> I2P'yi uzun süre çalıştırınca başarısız olan istemcilerde korkunç sıçramalar gördüm... 1)'e uyuyor mu bilmiyorum 15:39 <jrandom> KBlup: bu, yüksek CPU yükü ya da bant genişliği tüketimiyle ilişkili mi? 15:40 <KBlup> msg-delay> 10000ms ile sonuçlanıyor :-/ 15:40 <jrandom> ah, muhtemelen _PRE net'in geliştiriliyor olmasının nedenlerinden biri :) 15:40 <KBlup> Sanırım sonra yeni tunnels kurmaya çalışıyor ve sürekli başarısız oluyor, bu da bazen 300+ iş'e yol açıyor... 15:41 <KBlup> makinem oldukça güçlü ama bununla aşırı yükleniyor... 15:41 <jrandom> evet, bunların hepsi 0.6.1.10 için baştan elden geçirildi, hazır olana kadar sabredin 15:43 <jrandom> tamam, 1) hakkında başka bir şey var mı, yoksa yavaşça 2) _PRE net ilerlemesi'ne geçelim mi 15:43 <+Complication> 0.6.1.10 gerçekten kayda değer değişiklikler içeriyor gibi görünüyor 15:45 <jrandom> evet, burada çok malzeme var. Mevcut durum şu: yeni oluşturma kodu yerinde ve düzgün çalışıyor gibi görünüyor, fakat şimdi bu fırsatı bazı altta yatan sorunları daha fazla hata ayıklamak için kullanıyorum 15:46 <+Complication> Önceden epey CPU zamanı ayırmak gerektiğinden bahsetmiştiniz 15:47 <+Complication> Bu maliyet artık herhangi bir tür tunnel inşasıyla ilişkilendirilecek mi? 15:48 <+Complication> (yani, inşadan önce kısa bir süre boyunca bir dizi ağır kripto işlemi yapmanız gerekecek) 15:48 <jrandom> evet, tüm tunnel kurma isteklerinin k ağır kripto işlemi yapması gerekecek (burada k = inşa edilen tunnel içindeki atlama sayısı) 15:49 <+Complication> Sormak istediğim... aralık sadece eskisinden daha mı sıkı, yoksa miktar da mı daha büyük? 15:50 <jrandom> Miktar hem daha büyük, hem daha küçük, hem de zamanlama daha sıkı. Daha sıkı; çünkü hepsi en başta yapılıyor. Daha büyük; çünkü önceki bir atlama reddederse bir atlama için şifrelemeyi atlayıp kısayol yapamıyoruz. Daha küçük; çünkü önceki atlamalar çok daha az başarısız oluyor. 15:51 <jrandom> ayrıca, önceki sürümlerden farklı olarak, artık tunnel istekleri için ElGamal/AES+SessionTag kullanmıyoruz - (oldukça) doğrudan ElGamal kullanıyoruz 15:52 <+Complication> …ve başarılı olacak nihai kümeyi bilmeden önceden hesaplanamaz, doğru mu? 15:52 <jrandom> Bu, önceden asimetrik bir işlem yapmadan hile yapabiliyorken artık hile yapmaya çalışmadığımız anlamına geliyor (çünkü hilenin kendisi bir saldırı sınıfını ortaya çıkarıyordu) 15:53 <+Complication> (eşler kümesi) 15:53 <jrandom> hmm, hangi eşlerin tunnel içinde sorulacağını bildiğinizi varsayarsak, kesinlikle önceden hesaplanabilir 15:54 <jrandom> yeni tunnel oluşturma süreci ayrı bir iş parçacığında yürütülüyor; böylece yük altında ana iş kuyruğunu yavaşlatmıyor ve kendini daha iyi kısabiliyor 15:54 <+Complication> Denemeler başarısız olursa, mevcut bilgi değişmediği sürece, kime sorulacağına dair birkaç kişiyi bildiğini de varsayabilir miyiz? 15:54 <jrandom> hmm, tam olarak takip edemiyorum 15:55 <+Complication> Yoksa yapı sıfırdan yeniden yapılmak zorunda olduğundan onları önceden bilmenin bir faydası yok mu? 15:56 <+Complication> (yani: en azından ElGamal'lar sıfırdan yeniden yapılmalı) 15:56 <jrandom> ah, yapı şu: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> yani, evet, bir sonraki atlama değişirse ElGamal yeniden yapılmalı 15:56 <jrandom> (önceden hesaplıyorsanız) 15:56 <+Complication> Doğru, buna anında yeterince emin değildim 15:57 <+Complication> Ama şimdi anladım 15:57 <jrandom> diğer yandan, gerçekten inşa başarı oranımızı artırmaya çalışıyoruz ve yeni inşa süreci gereksiz oluşturumları en aza indirmek için uyum sağlayabilmeli 15:58 <+Complication> Gerçekte nasıl gidiyor gibi görünüyor? 15:58 <jrandom> (ah, o yapı _PRE dalında biraz değiştirildi: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) 15:59 <+Complication> ElGamal şifrelemelerinin hız konusunda sıçrama yaptığı ayrıntısını fark ettim... 15:59 <jrandom> inşa başarı oranı canlı ağdakinden çok daha yüksek, ancak bu sadece _PRE net'in küçük boyutundan kaynaklanıyor olabilir 16:00 <jrandom> evet, örneğin 2 atlamalı bir yapı oluşturmak 1120 çalıştırmada ortalama 44ms sürüyor; canlı ağdaki ElGamal şifreleme süresi ise 1344 çalıştırmada 542ms 16:02 <jrandom> (aynı makinede) 16:02 <+Complication> Bu 542, başarısızlık halinde yeniden denemeleri de içeriyor mu, yoksa sadece saf inşayı mı? 16:02 <+Complication> Eğer saf inşa ise alt çenemi bulmam gerekecek... bir yerde yerde olmalı. :P 16:02 <KBlup> üsdeki o değişiklik hakkında: bu anonimliğe hangi ölçekte etki eder? 16:02 <jrandom> hayır, bu saf ElGamal istatistiği, çünkü canlı ağ yeni _PRE net yapısını inşa etmiyor 16:04 <jrandom> KBlup: anonimlik? hiç. güvenlik? okuduklarıma göre 228 bit, 2048 bit ElGamal ile denk seviyede olmak için fazlasıyla yeterli 16:04 * Complication ElGamal'ın x ve y'si hakkında fazla bir şey bilmiyor 16:04 <+Complication> Anlamlı yorum yapacak kadar değil 16:06 <+Complication> Ciddi araştırmacılar daha kısa x'i yeterince zor olarak görüyorsa ve o kripto uzmanları çığlık atarak kaçmadıysa... 16:06 <@cervantes> yalnız o değil, 1024/160'a düşmenin sonuçları da 16:07 <KBlup> sanırım makaleyi sonra okumam gerekecek ;) 16:07 <+Complication> cervantes: evet, kesinlikle ondan daha iyi 16:08 <+Complication> Ayrıca, bu şifrenin geri püskürtmesi gereken en başta gelen saldırı nedir ve saldırı ne kadar süreyle uygulanabilir? 16:09 <+Complication> Yalnızca çabucak kırarsanız işe yarayan bir şey mi, yoksa eninde sonunda kırarsanız da fayda sağlar mı? 16:11 <+Complication> Doğru anlıyorsam, koruduğu anlık sır bir sonraki tunnel katılımcısı, değil mi? 16:11 <+Complication> (daha doğrusu, bir sonrakinin bir sonraki) 16:11 <@modulus> toplantı devam ediyor mu? 16:11 <+Complication> (ki bunu sadece bir sonraki bilebilir) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> pratik (ama akıl almaz derecede güçlü) bir saldırgan için, tunnel ömrü sırasında kırması gerekir. tunnel ömrü bittikten sonra kırmak ancak tüm ağ trafiğini kaydettiyseniz ve tüm tunnel'ları kırdıysanız işe yarar (yani, geçici taşıma katmanı kriptosunu kırdıktan sonra tunnel katmanı kriptosuna çalışarak) 16:11 <jrandom> yani, burada on yıllardan değil, dakikalardan söz ediyoruz 16:12 <jrandom> (yani 1024 bit muhtemelen bile fazla) 16:12 <@cervantes> riski anlamlı bir şekilde ölçmenin bir yolu var mı? 16:13 <+Complication> Ayrıca, daha fazla atlamalı bir tunnel için saldırganın birkaçını birden kırması gerekir, değil mi? 16:13 <+Complication> (gerçi kurucu da birkaçını inşa etmek zorunda kalacak) 16:13 <@cervantes> 1024 bitten fazlasına ihtiyacımız yoksa, daha fazlasını kullanmak gerçekten gerekli mi? 16:14 <@cervantes> Çok daha güçlü kuantum bilgisayarlarımız olduğunda 3 yıl sonra her zaman daha güçlü bir algoritma kullanabiliriz 16:14 <@modulus> jrandom: eğer saldırgan hh:mm saatinde önemli bir şeyin tunnelleneceğini bilse, kayıt tutarak bir şekilde bunu kırmayı başarabilir mi? 16:14 <jrandom> Complication: doğru, birkaçını kırmaları gerekir (ve taşıma katmanını koruyan DH anahtarlarını da) 16:14 <@modulus> bildiğim kadarıyla 1024 bit break() edilebilir, çok güçle 16:15 <jrandom> çok güç ve bir on yıl 16:15 <jrandom> (ya da üç) 16:15 <@cervantes> jrandom: daha zayıf şifreyi denemek zor mu? 16:15 <@modulus> 1024 bit bileşiklerin bugünlerde birkaç ayda çarpanlara ayrılabildiği izlenimine sahiptim. 16:15 <@cervantes> pre net'e yayabilir miyiz 16:15 <@cervantes> ve gerçekten çok fayda sağlayıp sağlamadığını görebilir miyiz 16:16 <@cervantes> modulus: evet, ama birkaçını kırmaları gerekecek 16:16 <@modulus> bu ayrık logaritma alanına ve o şeylere dayanıyorsa, o zaman hiçbir şey bilmiyorum 16:16 <@modulus> cervantes: aha 16:16 <jrandom> cervantes: çok sayıda yapıda değişiklik gerektiriyor, çünkü şu anda 512 baytlık yuvalar kullanıyoruz. yine de, belki test için ilk 256 baytı 0x00 ile doldurabiliriz 16:17 <jrandom> modulus: ElGamal ayrık logaritmaya dayanır 16:17 <@cervantes> jrandom: test etmeye değer mi? 16:17 <@modulus> doğru doğru, ben RSA hayal ediyordum 16:17 <@cervantes> yoksa diğer şeylere odaklanıp gerekirse buna geri dönmek daha mı iyi 16:18 <jrandom> kesinlikle test etmeye değer, ancak şu an bazı taşıma katmanı değerlendirmeleri üzerinde uğraşıyorum 16:18 <+Complication> Sanırım hesaplamalarının gerçek hayatta nasıl ele alınabileceğine bağlı 16:18 <jrandom> (ve 44ms şifreleme süresi şimdilik yeterince iyi, gerçi 4ms şifreleme süresi daha da iyi olurdu :) 16:19 <+Complication> Mevcut bilgisayarlarla başa çıkabiliyorsa, yeni makinelerle daha da iyileşir. 16:19 <@modulus> özellikle bazı yerlerde gelmeye başlayan kripto donanımı, (hw) gelirse 16:19 <jrandom> ama elbette, bu parametreyi değiştirmek hafife alınarak ya da hemen yapılmayacak. fakat kaçınılması için iyi bir nedeni olan biri varsa, lütfen temas kurun 16:21 <jrandom> modulus: özel AES ve RSA çiplerini duydum, ama DH/ElGamal için bir şey yok. diğer yandan, hasım olarak NSA/vb.'ye bakarsak, kendi donanımlarını yapabildikleri için mümkün 16:22 <@cervantes> halka şekerlemeli donut teknolojisiyle inşa edilmiş kripto makineleri var 16:23 * Complication, halka-şekerlemeli donut dalgasına dayanacaksa Celeron 300'ü Athlon 600'e yükseltmeye razı :D 16:23 <tethra> heheh 16:24 <jrandom> mmMMmm donutlar 16:25 <jrandom> tamam, 2) _PRE net ilerlemesi hakkında başka bir şey var mı? 16:25 <jrandom> yoksa, 3) I2Phex 0.1.1.37'ye geçelim 16:26 <jrandom> Complication: bize kısa bir özet vermek ister misin? 16:26 <+Complication> Şey, çalışıyor gibi görünüyor. :) 16:26 <+Complication> Yakında ek yedeklilik için daha fazla web önbelleği (webcache) elde etme umudu var. 16:27 <jrandom> aynen 16:27 <jrandom> hmm, daha fazla webcache'e ihtiyacımız olduğunu düşünüyor musun? sadece birinin ayakta olması yetmiyor mu? elbette fazlası zarar vermez 16:27 <+Complication> (legion ilk denemesini gölgeleyen gizemleri çözmeyi başarırsa) 16:27 <+Complication> Orada gizemli bir hata da var, ama çok ısırmıyor ve onu bulmaya çalışıyorum. 16:28 <+Complication> Bir tanesinin açık olması yeterli 16:28 <+Complication> Daha fazlası, bir tanesinin açık olma olasılığını sadece artırır 16:28 <jrandom> güzel 16:28 <+Complication> Çünkü mevcut aşamada, webcache'leri kötü diye asla listeden düşürmeyecek. Zaten sayıları çok az. 16:29 <+Complication> (o rutin 10'dan fazla varsa etkinleşecek) 16:29 <+Complication> (yanılmıyorsam) 16:29 <+Complication> Hata konusuna gelirsek: uzun süre çalıştıktan sonra webcache alt sistemi bazen takılıyor 16:30 <+Complication> Muhtemelen bir httpclient'ın GET isteği başarıyla iptal edilemediği için 16:31 <@modulus> yani ara sıra ölmesi mi gerekiyor? 16:31 <+Complication> Güvenli ve yeni katılan makineleri asla ısırmıyor gibi görünüyor 16:31 <jrandom> hmm, bu işlevsel olarak ne anlama geliyor? bir süre sonra webcache'e kayıt olmayı bırakacak, yani yenilere onlara dair referanslar verilmeyecek mi? 16:31 <+Complication> İyi entegre olmuş bir makineyi ısırırsa, o makine zaten bağlı olduğu eşlerden yeterince eş edinebilir 16:31 <+Complication> Yani şu anda etkisi 0'a yakın görünüyor 16:31 <@modulus> güzel 16:32 <+Complication> Sadece merak uyandırıcı 16:32 <@modulus> ne zaman başarısız olacağına dair bir kural falan yok mu? 16:32 <+Complication> modulus: genelde 20 saatten önce değil 16:33 <+Complication> Ve gerçekleşmeye zorlayacak bir yolum olmadığından hata ayıklama biraz yavaş 16:33 <@modulus> :_) 16:34 <+Complication> Her halükârda, bulursam düzelteceğim; bulamazsam oyalanacak başka şeyler bulacağım :) 16:34 <jrandom> :) 16:34 <jrandom> streaming lib / eepproxy'de gördüğümüz bazı hataların bir semptomu gibi geliyor, dolayısıyla onları düzeltmek bunu da düzeltecektir 16:35 <+Complication> Olabilir 16:38 <jrandom> tamam harika, güzel iş Complication 16:38 <jrandom> 3) I2Phex 0.1.1.37 hakkında başka bir şey var mı, yoksa hepsini kapsayan 4) ???'ye geçelim mi? 16:41 <jrandom> (geçmiş sayın) 16:41 <jrandom> tamam, toplantı için başka bir şey var mı? 16:42 <tmp> Ya da sonsuza dek nefesini mi tutarsın? 16:43 <jrandom> ve sonsuza dek 16:43 * jrandom toparlar 16:43 * jrandom toplantıyı *baf* ederek kapatır