Je SSL/TLS navržené záměrně slabě?

[kdokoliv]

a hadani velikosti rekey bloku je pak uz jen tresnicka na dortu pro zpresneni... ta je v podstate mimo. nez to je mnohem zasadnejsi leak nejpravdepodobneji pouzitych moznosti z moduli pres verzi ssh na zacatku spojeni.

[Reklama]

[pepak]

pokud je ten utok dostatecne dlouhy a systematicky, tak tam ta sance musi rust bez ohledu na silu rng.

Proto se používají tak dlouhé klíče, aby toto nehrálo roli. Myšlenka je asi taková, že je vcelku jedno, jestli je střední očekávaná doba prolomení klíče zkoušením hodnot rovna deset miliard krát stáří vesmíru nebo jen jedna miliarda krát stáří vesmíru, a dokonce by nám asi nějak zvlášť nevadilo, ani kdyby to bylo pouze milionkrát stáří vesmíru.

[kdokoliv]

jenze to je na 100% jistotu... ale kolik to bude na 50% tyden?

[Zopper]

Jak na 50 %? Buď ten klíč máš, nebo ne. Půlka klíče ti je na *píp*. Samozřejmě, pokud náhodou budeš mít klíč v podobě samých nul a někdo zkusí bruteforce a začne zrovna tím tvým klíčem, pak ta doba byla pár milisekund. Ale vůči tomuto imho nejde udělat odolný algoritmus.

[jenda]

zkuste bez gugla : kolik lidi se musi sejit, aby byla vice nez 50% pravdepodobnost, ze maji nekteri 2 narozeniny ve stejny den ?

[Reklama]

[pepak]

jenze to je na 100% jistotu... ale kolik to bude na 50% tyden?

Záleží na použité šifře, ale typicky se tím doba zkrátí na polovinu. U některých algoritmů (ale šifrovacích spíš ne, to je doména hlavně hashovacích funkcí; ovšem když vezmeme v úvahu kvantové počítače...) se může zkrátit i na odmocninu doby, takže řádově jednotky stáří vesmíru.

Jinými slovy: Řešíš problém, který nemá smysl řešit. Zaměř se spíš na to, jestli ve svém počítači nemáš trojana, který by klíče odchytával a posílal jinam.

[kdokoliv]

s tim bych prave dost zasadne nesouhlasil, kdyz ma moduli jen 262 prvocisel na vyzkouseni misto nekonecna. pokud bych chtel cist stara data tak jo, ale ne pokud chci podvrhnout server key.

[Sten]

vychazim z toho, ze me nezajima minula komunikace, ale jde o systematicky sber pres vsechny uzivatele s cilem ziskat server key a podvrhnout falesny server s duveryhodnym server key.

z rng mi nikdy nevyleze nekonecno, protoze je oriznuty velikosti pouzitou v protokolu. takze kdyz mam jednoznacne roztridene uzivatele podle adresy, tak mam i jednoznacne roztridene kex a melo by jit snaz hadat server key kdyz posbiram co nejvic neznamych pocatecnich session key a vysledku jejich sifrovani a mam je predtrizene do skupin podle IPv6 ktera je svazana s neznamym ale stalym privatnim user key. pokud je ten utok dostatecne dlouhy a systematicky, tak tam ta sance musi rust bez ohledu na silu rng.

Ta šance ale neroste. Session key jsou náhodně generované a při dostatečně silném RNG nedokážete najít souvislost s klíčem (které se navíc v normálních operačních systémech generuje jiným RNG než session key).

Btw. je mnohem spolehlivější třídit ty uživatele podle jejich veřejného klíče, který je součást každého spojení, obzvlášť když se adresa u IPv6 Privacy Extensions pořád mění ;-)

zkuste bez gugla : kolik lidi se musi sejit, aby byla vice nez 50% pravdepodobnost, ze maji nekteri 2 narozeniny ve stejny den ?

Je to o trochu víc než odmocnina z 365. Ale nemá to moc společného s prolamováním klíčů, birthday paradox se projevuje u hashů. Hashe se sice používají jako podpisy certifikátů, ale u 256-bitového hashe se tak dostanete do situace, že potřebujete vyzkoušet 2¹²⁸ hodnot (= 8 stáří vesmíru při miliardě vyzkoušených hodnot za sekundu), abyste s 50 % šancí našel kolizi, navíc ta kolize pravděpodobně nebude původní hodnota, takže sice můžete podvrhnout serverový certifikát, ale nebude to stejný serverový certifikát jako originální (takže třeba Certificate Patrol ve Firefoxu vás odhalí).

Btw. když budete mít 20 klíčů místo jednoho, tak odmocnina ze 20 není zrovna číslo, které by hrálo významný rozdíl

[pepak]

s tim bych prave dost zasadne nesouhlasil, kdyz ma moduli jen 262 prvocisel na vyzkouseni misto nekonecna. pokud bych chtel cist stara data tak jo, ale ne pokud chci podvrhnout server key.

IMHO je poněkud krátkozraké zásadně nesouhlasit tam, kde k tomu nemám znalosti, ale pokud ti to udělá radost...
Jak jsi přišel k těm svým číslům???

Jako ne že by v SSL nemohla být zásadní chyba, nebylo by to poprvé, ale stejně - typicky je nejslabším místem uživatel (jako že má slabé heslo k soukromému klíči nebo si před šifrováním nainstaluje keylogger), potom konkrétní implementace v nějakém programu (jako že v SuperBrowser v15.4 je SSL chybně implementováno a umožňuje snadné prolomení), a teprve potom návrh protokolu jako takový. (A ještě někde daleko dál šifra, kterou ten protokol používá.) Není moc efektivní soustředit se na protokol, pokud nemáš vyřešené to ostatní.

[kdokoliv]

Btw. je mnohem spolehlivější třídit ty uživatele podle jejich veřejného klíče, který je součást každého spojení, obzvlášť když se adresa u IPv6 Privacy Extensions pořád mění ;-)

no a to je ta dalsi lez. IPv6 privacy neni privacy. proste cely blok adres bude jeden uzivatel s jednim klicem. zatim co v IPv4 to bylo hledani slamene jehly v kupce sena, tak IPv6 je to hledani kovove jehly v kupce sena s tim, ze dame treti strane detektor kovu a magnet.

[Sten]

Btw. je mnohem spolehlivější třídit ty uživatele podle jejich veřejného klíče, který je součást každého spojení, obzvlášť když se adresa u IPv6 Privacy Extensions pořád mění ;-)

no a to je ta dalsi lez. IPv6 privacy neni privacy. proste cely blok adres bude jeden uzivatel s jednim klicem. zatim co v IPv4 to bylo hledani slamene jehly v kupce sena, tak IPv6 je to hledani kovove jehly v kupce sena s tim, ze dame treti strane detektor kovu a magnet.

Hmm, tady někdo neví, k čemu slouží Privacy Extensions Smyslem Privacy Extensions je znemožnit sledování mobilního klienta, tj. klienta, který mění sítě, a oddělení jednotlivých klientů uvnitř sítě. Bez Privacy Extensions by měl klient pořád stejnou druhou polovinu adresy, bez ohledu na síť, do které se připojuje. Co se týče oddělení jednotlivých klientů, tak samozřejmě pokud máte v síti jen jednoho klienta, tak vám Privacy Extensions moc nepomůžou, ale s mobilními telefony, tablety, čtečkami knih a chytrými televizemi na to už nemůžete spoléhat.

Nevím, jak jste přišel na to, že by IPv4 NAT měl v tomhle nějakou výhodu oproti IPv6 sítím. Dnes má každý uživatel u normálních operátorů (UPC, O₂, Vodafone, U:fon, ze zahraničních má vyzkoušeno třeba Verizon, Sky, Sprint, Rodger Wireless, Nextra, Aircell ap.) jednu veřejnou IPv4 adresu, kterou můžete použít úplně stejně (ta veřejná IPv4 adresa se mu přiděluje stejně náhodně jako IPv6 síť). Navíc nikdo vám nezaručuje, že ten jeden uživatel má právě jeden počítač s jedním klíčem, a to ani u IPv4 ani u IPv6 sítí. Veřejné klíče jsou pro tohle mnohem spolehlivější.

[fail]

tak samozřejmě pokud máte v síti jen jednoho klienta, tak vám Privacy Extensions moc nepomůžou

na tuhle cast IEEE newspeaku jsem narazel.

[fail]

tak samozřejmě pokud máte v síti jen jednoho klienta, tak vám Privacy Extensions moc nepomůžou

na tuhle cast IEEE newspeaku jsem narazel.

pardon. IETF. omluva IEEE.

[Sten]

tak samozřejmě pokud máte v síti jen jednoho klienta, tak vám Privacy Extensions moc nepomůžou

na tuhle cast IEEE newspeaku jsem narazel.

Privacy není anonymity

[fail]

tak samozřejmě pokud máte v síti jen jednoho klienta, tak vám Privacy Extensions moc nepomůžou

na tuhle cast IEEE newspeaku jsem narazel.

Privacy není anonymity

pro statickeho klienta je to argument asi jako dat si velkoformatovou fotku sebe ze swingers jako roletu do loznice a nedat si na zvonek jmenovku, ale znat se se vsemi sousedy a mit jmeno na katastru.