Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: kdokoliv 21. 07. 2014, 15:20:44
-
Jak hodnotite absenci podpory vicenasobnych soukromych klicu pro jeden par klient - server u TLS spojeni?
Kolik rozdilnych overenych a povolenych soukromych klicu soucasne povazujete pro ten stejny par klient - server povazujete za primerenou miru anonymity v pripade prolomeni sifrovani s vynucenim si nutnosti lamat dalsi nahodne vybrany overeny klic vs. primereneho zabezpeceni tim, ze nebude prilis mnoho povolenych klicu?
A nebavim se ted o session klicich a reinicializaci, ale prave o obdobe ~/.ssh/authorized_keys a ~/.ssh/config
Host *
IdentityFile ~/.ssh/a
IdentityFile ~/.ssh/b
IdentityFile ~/.ssh/c
...
-
Použití více šifer v sobě zvyšuje bezpečnost jen omezeně, často je naopak kontraproduktivní a nakonec stejně záleží hlavně na první vrstvě (http://en.wikipedia.org/wiki/Multiple_encryption). Nevím, co mají klíče společného s anonymitou, to asi spíš hledáte Perfect Forward Secrecy (http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy) nebo Off-the-Record Messaging (http://en.wikipedia.org/wiki/Off-the-Record_Messaging).
TLS (i SSH) používá ty dva páry klíčů jen pro vygenerování symetrického klíče, vše ostatní se již šifruje tím symetrickým klíčem, protože je to výrazně rychlejší.
-
Ano je to narazka na tu matematickou lez "Perfect" Forward Secrecy, ktera je cokoliv jen ne perfect, ale spis SuperResistant Forward Secrecy a jakym zpusobem ji obejit, kdyz ani ssh nevybira z vice identity klicu nahodne. Kolik lidi si je toho vedomych.
-
Ano je to narazka na tu matematickou lez "Perfect" Forward Secrecy, ktera je cokoliv jen ne perfect, ale spis SuperResistant Forward Secrecy a jakym zpusobem ji obejit, kdyz ani ssh nevybira z vice identity klicu nahodne. Kolik lidi si je toho vedomych.
Jakým způsobem obejdete PFS, když používá jednorázové klíče?
-
obejitim PFS. treba slovnikovym utokem na KEX.
citaci z te wiki stranky utokem na "where the long-term secrets are private keys"
bude to chtit kupu datacenter... mozna tolik kolik jich ma NSA...
-
obejitim PFS. treba slovnikovym utokem na KEX.
citaci z te wiki stranky utokem na "where the long-term secrets are private keys"
bude to chtit kupu datacenter... mozna tolik kolik jich ma NSA...
To rovnou můžete prolomit i těch pár dalších soukromých klíčů, nárůst složitost v řádu jednotek je v kryptografii nepoužitelný.
-
vychazim z toho, ze ten utok neni 100% ale jen pravdepodobnostni a ta pravdepodobnost se zvysuje s tim, jak se opakuji vzory v prenasenych datech, takze pri 365 spojenich rocne a 365 jednorazovych soukromych klicich se mi bude darit drzet pravdepodobnost uhodnuti reinicializovaneho session key nepouzitelne nizko zatim co pri znovu-pouziti to nemusi byt zdaleka tak jednoznacne.
-
vychazim z toho, ze ten utok neni 100% ale jen pravdepodobnostni a ta pravdepodobnost se zvysuje s tim, jak se opakuji vzory v prenasenych datech, takze pri 365 spojenich rocne a 365 jednorazovych soukromych klicich se mi bude darit drzet pravdepodobnost uhodnuti reinicializovaneho session key nepouzitelne nizko zatim co pri znovu-pouziti to nemusi byt zdaleka tak jednoznacne.
Ty soukromé klíče se používají jen pro D-H, ne pro přenášená data. Těch dat, ze kterých by se to dalo louskat, je velmi málo, i kdybyste měl stovky přenosů denně.
Btw. u PFK by nemělo jít uhodnout session key podle předchozích session key, jinak to není PFK
-
hacek je v tom, ze tam nikde neni schovane nekonecno, takze je jistota, ze s objemem dat blizicim se k nekonecnu pujde pri absurdnich investicich dosahnout pravdepodobnosti blizke 100% sance uhodnuti... takze je potreba zborit tu moznost sesbirat neco blizkeho nekonecnu dat. a jednorazove klice asi nejsou taky uplne to spravne reseni. ale spis nahodna jednorazovost s tim, ze ostatni se muzou pouzit znovu.
-
hacek je v tom, ze tam nikde neni schovane nekonecno, takze je jistota, ze s objemem dat blizicim se k nekonecnu pujde pri absurdnich investicich dosahnout pravdepodobnosti blizke 100% sance uhodnuti... takze je potreba zborit tu moznost sesbirat neco blizkeho nekonecnu dat. a jednorazove klice asi nejsou taky uplne to spravne reseni. ale spis nahodna jednorazovost s tim, ze ostatni se muzou pouzit znovu.
PFS je tak bezpečné, jak bezpečné je RNG, které používá. Pokud se bojíte prolomení PRNG běžných operačních systémů, použijte něco pořádně náhodného (https://www.fourmilab.ch/hotbits/). (Btw. PFS používá de facto jednorázové klíče, které se pouze vymění pomocí D-H šifrovaného asymetickou šifrou.)
Střídání klíčů navíc nezpůsobí prolamujícímu korupci vstupních dat, protože na začátku každého přenosu se přenese veřejný klíč (aby druhá strana věděla, čím má vlastně šifrovat D-H), takže je celkem triviální seskupit jednotlivé komunikace podle použitých klíčů.
Mimochodem SSL ani SSH nijak nespecifikují, odkud se mají ty klíče získat, to je věc implementace. Klidně můžete mít množinu klíčů a pro každý přenos vybrat jeden náhodně.
-
Ja ale neresim primarne bezpecnost RNG, ale odstraneni steganograficke nadstavby nad SSL/TLS. S prechodem od IPv4 NAT k IPv6 a to nejen mobilni roaming, ale vcetne te lzi nazvane IPv6 privacy.
-
Ja ale neresim primarne bezpecnost RNG, ale odstraneni steganograficke nadstavby nad SSL/TLS. S prechodem od IPv4 NAT k IPv6 a to nejen mobilni roaming, ale vcetne te lzi nazvane IPv6 privacy.
Jaké steganografické nadstavby? TLS se nijak nesnaží skrývat.
Co je na IPv6 Privacy Extensions lživého?
-
Chápu správně, že ti jde o útok, který by ze znalosti velkého množství podepsaných a/nebo zašifrovaných zpráv umožnil zlomit klíč? Myslím, že bude podobně nepravděpodobný, jako útok, který by ze znalosti jedné této dvojice umožnil prolomit jeden klíč z tisíce, kdy zase tvé řešení jasně uškodí.
-
je potreba zborit tu moznost sesbirat neco blizkeho nekonecnu dat.
No, nějak mi hlava nebere, jak chceš během jednoho roku (než starý pár klíčů zahodíš a vytvoříš nový) vygenerovat nekonečně dat.
-
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.
-
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.
-
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.
-
jenze to je na 100% jistotu... ale kolik to bude na 50% tyden?
-
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.
-
zkuste bez gugla : kolik lidi se musi sejit, aby byla vice nez 50% pravdepodobnost, ze maji nekteri 2 narozeniny ve stejny den ?
-
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.
-
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.
-
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 ;)
-
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í.
-
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.
-
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ší.
-
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.
-
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.
-
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 :)
-
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.
-
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.
Opět si pletete soukromí (privacy) a anonymitu.
-
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.
Opět si pletete soukromí (privacy) a anonymitu.
treba jen nemam rad lidi co slovickari.
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í
kdyz uz jsme u toho hnidopistvi... ze ja se tu vubec s vama bavim, kdyz ani nemate poneti, ze tohle udelat nelze, protoze tahle cast u DHGEX neni soucasti sestaveni transportu.
-
teda pokud to dokazete, tak umite prolomit session key nebo rng.
kazdopadne na dlouhodobem opakovani tech dat v ramci auth faze je postavena ta domenka statistickeho utoku.
-
Opět si pletete soukromí (privacy) a anonymitu.
treba jen nemam rad lidi co slovickari.
Já nejsem ten, co si stěžuje, že Privacy Extensions jsou lživý název, a přitom jenom nerozumí tomu, co to znamená ;-)
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í
kdyz uz jsme u toho hnidopistvi... ze ja se tu vubec s vama bavim, kdyz ani nemate poneti, ze tohle udelat nelze, protoze tahle cast u DHGEX neni soucasti sestaveni transportu.
Odkdy se nebavíme o TLS?
-
Uz docela od zacatku. Ale to SSH tu pristalo po tom co tu nekdo odignoroval polovinu moznych TLS handshaku prave proto, ze se na nem nemusi prilis casto vysvetlovat o kterou cast jde.
-
:-X
-
a nebo prece jen jedno rejpnuti...
> deset miliard krát stáří vesmíru nebo jen jedna miliarda krát stáří vesmíru
256 spojeni na 1 byte (8 bitu)... to mi prijde jako mizerna zivotnost vesmiru... 256 / 10miliard.