Setkání vývojářů I2P - 7. února 2006

15:36 <jrandom> 0) ahoj 15:36 <jrandom> 1) Status sítě 15:36 <jrandom> 2) Průběh _PRE net 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) ahoj 15:37 * jrandom mává 15:37 <jrandom> týdenní poznámky ke stavu zveřejněny @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> ahoj 15:38 <jrandom> zatímco se probíráte tím oh-tak-vzrušujícím materiálem, pojďme skočit do 1) Status sítě 15:38 <jrandom> na živé síti se z pohledu i2p za poslední týden moc nezměnilo, takže tu nemám moc co dodat 15:39 <jrandom> má někdo něco, co chce zmínit ohledně aktuálního stavu sítě? 15:39 <KBlup> viděl jsem hrozné špičky selhávajících klientů při dlouhém běhu i2p... nevím, jestli to patří k 1) 15:39 <jrandom> KBlup: koreluje to s vysokým zatížením CPU nebo spotřebou šířky pásma? 15:40 <KBlup> výsledkem je msg-delay> 10000ms :-/ 15:40 <jrandom> aha, to je velmi pravděpodobně jeden z důvodů, proč se vyvíjí _PRE net :) 15:40 <KBlup> myslím, že se pak snaží navázat nové tunnels a neustále to selhává, což někdy vede k 300+ úlohám... 15:41 <KBlup> můj stroj je docela silný, ale tímhle přetížený... 15:41 <jrandom> jo, to všechno bylo přepracováno v rámci 0.6.1.10, vydržte, než to bude hotové 15:43 <jrandom> ok, ještě něco k 1), nebo se přesuneme k 2) Průběh _PRE net 15:43 <+Complication> 0.6.1.10 skutečně obsahuje značné změny 15:45 <jrandom> jo, je tu hodně masa. Aktuální stav je, že nový kód pro vytváření je na místě a zdá se, že funguje správně, ale teď využívám příležitosti dál ladit některé podkladové problémy 15:46 <+Complication> Zmiňoval jsi, že je potřeba předem vyplivnout hodně CPU času 15:47 <+Complication> Bude tenhle náklad teď spojen se stavbou jakéhokoli tunnel? 15:48 <+Complication> (tj. před samotnou konstrukcí bys během krátké chvíle musel provést dávku těžkého crypto) 15:48 <jrandom> ano, všechny požadavky na build tunnel budou muset provést k náročných crypto operací (kde k = počet hopů v buildovaném tunnel) 15:49 <+Complication> Chtěl jsem se zeptat... je interval jen těsnější než dřív, nebo je i objem větší? 15:50 <jrandom> objem je zároveň větší, menší i těsnější. Těsnější v tom, že se všechno udělá předem. Větší v tom, že nemůžeme zkratovat a vynechat šifrování pro nějaký hop, když ho předchozí hop odmítne, a menší v tom, že dřívější hopy selhávají mnohem méně 15:51 <jrandom> navíc, na rozdíl od dřívějších vydání už pro požadavky na tunnel nepoužíváme ElGamal/AES+SessionTag – používáme (celkem) přímo ElGamal 15:52 <+Complication> ...a nedalo by se to předpočítat, ledaže by člověk znal finální sadu, která projde? 15:52 <jrandom> to znamená, že zatímco dřív jsme mohli podvádět bez asymetrické operace, už se o to nepokoušíme (protože samotné to obcházení odhalovalo jistou třídu útoků) 15:53 <+Complication> (sada peers) 15:53 <jrandom> hmm, určitě by se to dalo předpočítat, pokud víš, kteří peers v tom tunnel budou osloveni 15:54 <jrandom> nový proces vytváření tunnel běží v samostatném threadu, takže pod zátěží neucpe hlavní frontu úloh a může se lépe škrtit 15:54 <+Complication> Dá se také předpokládat, že pokud se nezmění dostupné poznatky, člověk ví o pár těch, které bude oslovovat, když pokusy selžou? 15:54 <jrandom> hmm, nejsem si úplně jistý, že rozumím 15:55 <+Complication> Nebo je jejich znalost beztak k ničemu, protože se ta struktura musí udělat znovu od nuly? 15:56 <+Complication> (tj.: alespoň ElGamal(y) znovu od nuly) 15:56 <jrandom> aha, struktura je http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> takže ano, pokud se změní next hop, ElGamal se musí udělat znovu 15:56 <jrandom> (pokud předpočítáš) 15:56 <+Complication> Jasně, hned jsem si tím nebyl jistý 15:57 <+Complication> Teď mi to dochází 15:57 <jrandom> na druhou stranu se opravdu snažíme zvednout úspěšnost buildů a nový build proces by se měl umět přizpůsobit, aby minimalizoval zbytečná vytváření 15:58 <+Complication> Jak to vypadá v praxi? 15:58 <jrandom> (jo, ta struktura byla na větvi _PRE lehce upravená: 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> Všiml jsem si detailu, že šifrování ElGamal výrazně zrychlilo... 15:59 <jrandom> no, úspěšnost buildů je mnohem vyšší než na živé síti, ale to může být jen tím, že _PRE net je malá 16:00 <jrandom> jo, vytvoření struktury se 2 hop například trvá v průměru 44ms přes 1120 běhů, zatímco na živé síti trvá ElGamal šifrování 542ms (přes 1344 běhů) 16:02 <jrandom> (na stejném stroji) 16:02 <+Complication> Těch 542 zahrnuje i opakování při selhání, nebo je to jen čisté buildování? 16:02 <+Complication> Pokud je to čistý build, musím najít svou spodní čelist... někde leží na zemi. :P 16:02 <KBlup> k té změně exponentu: v jakém měřítku to ovlivňuje anonymitu? 16:02 <jrandom> ne, to je čistá statistika elGamal, protože živá síť nestaví tu novou strukturu _PRE net 16:04 <jrandom> KBlup: anonymita? žádná. bezpečnost? podle toho, co jsem četl, je 228 bitů víc než dost na úroveň 2048bit ElGamal 16:04 * Complication toho moc neví o ElGamalových x a y 16:04 <+Complication> Ne dost na smysluplný komentář 16:06 <+Complication> Pokud seriózní výzkumníci považují kratší x za dost těžké a ti crypto šílenci předtím neutekli s křikem... 16:06 <@cervantes> no, nejen to, ale i důsledky přechodu na 1024/160 16:07 <KBlup> asi si ten paper budu muset později přečíst ;) 16:07 <+Complication> cervantes: ano, to je určitě lepší 16:08 <+Complication> Mimochodem, jakému hlavnímu útoku se ten cipher musí bránit a jak dlouho je takový útok reálně proveditelný? 16:09 <+Complication> Je to něco, co ti pomůže jen když to prolomíš rychle, nebo pomůže i když to prolomíš až časem? 16:11 <+Complication> Jestli to chápu správně, bezprostřední tajemství, které to chrání, je další účastník tunnel, že? 16:11 <+Complication> (přesněji, ten přes další) 16:11 <@modulus> schůzka běží? 16:11 <+Complication> (kterého může znát jen ten další) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> pro praktického (byť šíleně silného) protivníka by bylo nutné to prolomit během lifetime daného tunnel. Prolomení po skončení lifetime toho tunnel by pomohlo jen tehdy, pokud by sis logoval veškerý síťový provoz a prolomil všechny tunnels (tj. poté, co prolomíš efemérní crypto na transport layer a pustíš se do crypto na tunnel layer) 16:11 <jrandom> takže se bavíme o řádu minut, ne desetiletích 16:12 <jrandom> (takže 1024bit je nejspíš i overkill) 16:12 <@cervantes> dá se to riziko nějak smysluplně změřit? 16:13 <+Complication> Kromě toho, u tunnel s více hop by protivník musel prolomit několik z nich, že? 16:13 <+Complication> (i když builder by musel také stavět několik) 16:13 <@cervantes> pokud nepotřebujeme víc než 1024 bitů, je opravdu nutné používat víc? 16:14 <@cervantes> vždy můžeme za 3 roky použít silnější algo, až budeme mít výrazně výkonnější kvantové počítače 16:14 <@modulus> jrandom: kdyby protivník věděl, že v čase hh:mm se bude tunnelovat něco důležitého, je pravděpodobné, že by to nějak prolomil logováním? 16:14 <jrandom> Complication: správně, museli by prolomit několik (a DH klíče, které chrání transport layer) 16:14 <@modulus> pokud vím, 1024bit je break()able s obrovským výkonem 16:15 <jrandom> obrovský výkon a tak deset let 16:15 <jrandom> (nebo tři) 16:15 <@cervantes> jrandom: je těžké zkusit slabší cipher? 16:15 <@modulus> měl jsem dojem, že 1024bitové kompozity jsou dnes faktorizovatelné během pár měsíců. 16:15 <@cervantes> mohli bychom to nasadit na pre net 16:15 <@cervantes> a zjistit, zda to skutečně přináší významný přínos 16:16 <@cervantes> modulus: ano, ale museli by jich prolomit několik 16:16 <@modulus> jestli je to založené na diskrétním logaritmu a všech těch věcech, tak o tom nic nevím 16:16 <@modulus> cervantes: aha 16:16 <jrandom> cervantes: vyžaduje to změny v mnoha strukturách, protože teď používáme 512byte sloty. Možná bychom ale pro testy mohli prvních 256 bytů prostě vyplnit 0x00 16:17 <jrandom> modulus: ElGamal je založený na diskrétním logaritmu 16:17 <@cervantes> jrandom: stojí to za otestování? 16:17 <@modulus> jasně, já si představoval RSA 16:17 <@cervantes> nebo je lepší soustředit se na jiné věci a vrátit se k tomu, pokud to bude potřeba 16:18 <jrandom> rozhodně stojí za test, ale momentálně se vrtám v nějakých evaluacích na transport layer 16:18 <+Complication> Asi to závisí na tom, jak se jejich výpočet dá zvládnout v reálu. 16:18 <jrandom> (a čas šifrování 44ms je pro teď dost dobrý, i když 4ms by byly ještě lepší :) 16:19 <+Complication> Když to drží pohromadě na současných počítačích, s novějšími stroji se to zlepší. 16:19 <@modulus> zvlášť pokud přijde crypto hw, jak už začíná u některých přicházet 16:19 <jrandom> ale změnu tohoto parametru samozřejmě neuděláme lehkovážně ani hned. Pokud má někdo dobrý důvod se tomu vyhnout, dejte prosím vědět 16:21 <jrandom> modulus: slyšel jsem o specializovaných čipech pro AES a RSA, ale nic pro DH/ElGamal. Na druhou stranu, když se jako protivník bere NSA/apod., kde si mohou vyrobit vlastní, je to možné 16:22 <@cervantes> mají crypto stroje postavené na technologii koblih s kroužkovým posypem 16:23 * Complication je ochotný upgradovat Celeron 300 na Athlon 600, pokud to udrží nápor kroužkově posypaných donutů :D 16:23 <tethra> heheh 16:24 <jrandom> mmMMmm donuty 16:25 <jrandom> ok, má ještě někdo něco k 2) Průběh _PRE net? 16:25 <jrandom> pokud ne, skočme na 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication: dáš nám info? 16:26 <+Complication> No, zdá se, že to funguje. :) 16:26 <+Complication> Je naděje brzy získat víc webcaches (webové cache) pro extra redundanci. 16:27 <jrandom> jasně 16:27 <jrandom> hmm, myslíš, že potřebujeme víc webcaches? Nestačí, aby běžela jedna? Ne že by víc bolelo, samozřejmě 16:27 <+Complication> (pokud se legionovi podaří vyřešit záhady, které strašily jeho první pokus) 16:27 <+Complication> Je tam taky záhadný bug, ale nekouše tvrdě, a snažím se ho najít. 16:28 <+Complication> Jedna dostupná stačí 16:28 <+Complication> Více jich jen zvyšuje šanci, že nějaká bude dostupná 16:28 <jrandom> cool 16:28 <+Complication> Protože v aktuální fázi to nikdy nevyřadí webcaches jako špatné. Celkově jich je příliš málo. 16:29 <+Complication> (ta rutina se aktivuje, pokud jich existuje víc než 10) 16:29 <+Complication> (pokud si dobře pamatuji) 16:29 <+Complication> K tomu bugu: po dlouhém běhu se subsystem webcache někdy zasekne 16:30 <+Complication> Pravděpodobně proto, že GET požadavek httpclienta nelze úspěšně zrušit 16:31 <@modulus> takže musí čas od času chcípnout? 16:31 <+Complication> Je to bezpečné a nikdy to zjevně nekouše čerstvě připojené stroje 16:31 <jrandom> hmm, co to znamená funkčně? Po čase přestane registrovat u webcache, takže novým lidem na ně nebudou dávané reference? 16:31 <+Complication> Když to kousne už dobře integrovaný stroj, ten si sežene dost peers od peers, na které je už připojený 16:31 <+Complication> Takže momentálně se dopad zdá být blízko nule 16:31 <@modulus> super 16:32 <+Complication> Je to jen zvláštní 16:32 <@modulus> žádné pravidlo, kdy to selže, nebo tak? 16:32 <+Complication> modulus: obecně ne dřív než po 20 hodinách 16:33 <+Complication> A protože nemám jak to vynutit, ladění je trochu pomalé 16:33 <@modulus> :_) 16:34 <+Complication> Každopádně, když ho najdu, opravím ho, a když ho nenajdu, najdu si jiné věci na hraní :) 16:34 <jrandom> :) 16:34 <jrandom> zní to, jako by to byl jen symptom některých bugů, které jsme viděli ve streaming lib / eepproxy, takže jejich oprava by měla opravit i tohle 16:35 <+Complication> Může být 16:38 <jrandom> ok super, dobrá práce, Complicatione 16:38 <jrandom> má někdo ještě něco k 3) I2Phex 0.1.1.37, nebo skočíme na sběrnou 4) ??? 16:41 <jrandom> (berte to, že jsme skočili) 16:41 <jrandom> ok, má někdo ještě něco na schůzku? 16:42 <tmp> Nebo už navždy mlčte? 16:43 <jrandom> a navždy a navždy 16:43 * jrandom se rozmachuje 16:43 * jrandom *baf* uzavírá schůzku