Dotaz: Openvpn nefunguje s klíči většími než 4096 b

[emet]

Dobrý den. Jako klienta mám ubuntu 10.04, server je centos 6.2. Pokud použiju pro openvpn certifikáty klíč o velikost větší než 4096 b (např. 8192), tak se spojení nenaváže a končí to chybou excessive message size v logu. V čem je problém a co bych měl aktualizovat? openvpn, openssl, ... ?

Odpovědi

[lertimir]

když paranoa tak pořádná.

[Kit]

Asi by bylo vhodné aktualizovat paranoiu. Pokud je možné prolomit 4096bitový klíč, stejně snadné bude prolomit i 8192bitový klíč. Jinými slovy jsem přesvědčen, že přechodem z 4096 bitů na 8192 bitů se bezpečnost takového klíče nijak nezvýší.

[emet]

No já nevím, poslední dobou se stále vzrůstajícím výpočetním výkonem je myslím za postačující velikost 3072. Třeba pro ssh používám rsa klíče o velikosti 16384 a fungují dobře.

[Zopper]

Až přijdou na trh kvantové stroje, tak nepomůže ani megabajtový klíč...

[lertimir]

Tak žhavé bych to neviděl. Podobně jako se v 60 a 70 letech říkalo: Až budou v provozu elektrárny na jadernou fůzi bude po problému z energií.

[Pindal]

Težko říct jestli bude nebo nebude

[lertimir]

Jako člověk se vzděláním z oboru matematická fyziky z MFF mám poměrně jasnou představu o kvanové fyzice, která za quantovým počítáním stojí. A podobně jako s tou fůzí, kde je poměrně jednoduché srazit dva atomy deuteria, aby se sloučily do hélia, ale mnohem složitější udělat to přímo na vodíku a už vůbec dosud ne, abych z toho sloučení získal více energie než do toho na ty srážky a sloučení vkládám, abych to udržel a nerozpadlo se to.

Podobně jasně si dokážu představit, jak u nějaké systému vyrobím kvantový stav superpozicí z několika a jak s němi operací budu pracovat. A s jednotkami takových systémů se pracuje dobře, s desítkami o mnoho řádů hůře a při skutečně velkém počtu bude udržení stability stavů za technickými hranicemi. Nicméně stejně tak si dokážu představi, že když bych v tomto dělal, tak je to nesmírně vzrušující práce, a krmit média vizemi jak to bude super, až to bude počítat, bych určitě také dělal.

[Pindal]

Se složitostí nijak nepolemizuji Jen si netroufám tvrdit jestli až budou funkční elektrárny s jadernou fůzí bude vyrešen nebo nevyřešen problém s energií

[d'areback]

Uvedom si, jake mas stesti, ze jsi nahmatal tak zrejmou chybu. Timhle pristupem jsi to taky mohl zahnat nekam do rohu, kde to nikdy nikdo netestoval, narazit na nejakou blbou chybu, pres kterou by ti tam mohli chodit nezvane navstevy. Extremy jsou k nicemu. Drz se doporuceni.

[lertimir]

To samozřejmě pravda není. S délkou klíče bezpečnost roste, nicméně klíče o velikosti 1024 odpovídají symetrickému klíči o velikosti 80, 2048 velikosti 112 a 3072 klíči 128. což je cca 10^24, 10^33 a 10^38 možností. Což jsou hodnoty, které když bychom měli systém, který má miliardu procesorových jader, každé z nich by bylo schopné vyhodnotit miliardu klíčů za sekundu (to se algoritmicky zvládnout nedá jsou na to asi 4 operace), přesto by hledání trvalo pro první klíč 10^6 pro druhý 10^15 a pro třetí 10^20 sekund, t.j. pro první klíč 11 dní, pro druhý 32 milionů let a pro třetí 3*10^12 let (což je více než od vzniku vesmíru).

Pokud nedojde k nějakému zásadnímu průlomu v matematice za teorií tak všechny klíče od 2048 výše se dají považovat za dostatečně bezpečné. Na druhou stranu od vzniku asymetrické kryptografie bylo hledání slabin jak v implementaci tak v teorii věnováno tolik úsilí tolika vynikajících mozků, že je málo pravděpodobné, že nějakou podstatnou díru si systém s sebou nese. Délky klíčů od 3072 výš mají stejný význam jako megapixely u současných kompaktů, nepřinášejí vůbec nic.

[Kit]

Tím jsi mi to jen potvrdil. Jakoukoli šifru s klíčem velikosti 2048 bitů a větší je v současné době možné prolomit pouze sociálním inženýrstvím.

A proto stále tvrdím, že ten, kdo dnes prolomí 4096bitovou šifru, stejně snadno prolomí i 16384bitovou.

[Michal Kubeček]

"Jen sociálním inženýrstvím", to je trochu přehnané. Spíš bych to formuloval tak, že u 2048-bitového (a nejspíš i 1024-bitového) klíče už je téměř jistě efektivnější vést útok jinudy, takže i snaha o zvýšení bezpečnosti by se měla zaměřit na skutečné potenciální slabiny.

[lertimir]

Souhlas. Nemusí to být jen sociálním inženýrství. V implementaci šifer a zvláště v implementaci protokolů je mnoho děr. Typická chyba při programové implementaci bývá, že systém při detekci chyby ihned reaguje a vrací chybu, případně ukončuje spojení nebo jinak se zachová. To může být významným zdrojem informací pro útočníka, protože zná-li implementaci protokolu (což u opensource je vždy), může odhadnout, že v případě, že uhodne-li část klíče(protokolu, komunikace), pak část zpracování proběhne korektně a on získá chybovou reakci později, a tento rozdíl časů mu pomůže odhadnout, jaká část komunikace proběhla korektně a v jaké části pak systém detekoval odlišnost a reagoval chybovým stavem. To má za následek, že v některých případech může hádat klič postupně.

Tyto chyby v designu aplikací už mají za následek mnoho použitelných útoků. Ale ruku na srdce, kdo z vás programuje tak, aby systém, když zachytí chybu počkal a odpověděl až v čase, kdy by doběhlo celé korektní zpracování.

A procesy řídící security policy jsou kapitola sama pro sebe.