Na faktorizaci velkých čísel jsem se specializoval na MFF na doktorském studiu, takže do téhle oblasti jsem jakžtakž ponořen.
<i>Nedojde-li k výraznému posunu v oblasti algoritmů</i> (a od roku 1993, kdy bylo popsáno Number Field Sieve, v podstatě nedošlo), nemáte šanci někdy za 10 let crackovat 4096-bitové RSA moduly jen nárůstem výpočetního výkonu. Maximum, které bych reálně očekával, je 1024 bitů.
Nutno ovšem říci, že vám nikdo nezaručí, že se nějaký „dělový“ algoritmus neobjeví. Proto jsou předpovědi na 10 a více let obvykle vaření z vody.
Docela by mne zajímalo, odkud citujete toho Bruce Schneiera a jeho názor na délky klíčů. Pokud vím, Schneierův názor v tomto je, že lidé dělají z délky klíčů zbytečný fetiš a zanedbávají přitom podstatně praktičtější a realističtější ohrožení, jako je kvalitní keylogger.
lenze z 1024-bitovych klucov sa prechadza uz teraz. preco si robit kluc o ktorom sa predpoklada dnes, ze dlho nevydrzi?
Applied Cryptography
Assume a dedicated cryptanalyst can get his hands on 10,000 mips-years, a
large corporation can get 107 mips-years, and that a large government can get
109 mips-years. Also assume that computing power will increase by a factor of
10 every five years. And finally, assume that advances in factoring
mathematics allow us to factor general numbers at the speeds of the special
number field sieve. (This isn't possible yet, but the breakthrough could occur
at any time.) Table 7.6 recommends different key lengths for security during
different years.
Table 7.6
Recommended Public-key Key Lengths (in bits)
Year vs. Individual vs. Corporation vs. Government
1995 768 1280 1536
2000 1024 1280 1536
2005 1280 1536 2048
Podívejte se pár příspěvků níže a počítejte:
Za 20 let se výpočetní kapacita možná zvětší 1000× – viz Moorův „zákon“. Dobrá, s rezervou počítejme 1000000×
Vládní instituce mají k dispozici výpočetní kapacitu, která je v nejlepším případě 10000000000× vyšší než obyčejné PC. A to nejspíš přeháním. Botnet ze všech stolních počítačů na světě by měl nanejvýš desetinu.
Pokud se nestane nic mimořádného, výpočetní kapacita vládních výpočetních center nebude za 20 let vyšší než 10000000000000000× násobek výpočetní kapacity obyčejného PC dnes.
Jenže zlomení 2048bitového klíče je 34996011596528190789960035633881941845650710894291398982812329702559247987190014771576210832368861184× složitější než zlomení 1024bitového klíče.
Za 20 let by tedy stále ještě bylo třeba 3499601159652819078996003563388194184565071089429139898281232970255924798719001477158 těch nejvýkonnějších vládních počítačů ke zlomení 2048bitové šifry.
Výpočet samozřejmě předpokládá, že nebude nalezeno slabé místo šifry.
„teraz si predstav aky posun spravilo vyuzitie grafickych akceleratorov.“
Na to jsme si dělali ve firmě takovou malou studii … posun je lineární, čili dlouhodobě nepodstatný.
Nejlepší algoritmus pro faktorizaci velkých čísel, General Number Field Sieve, je subexponenciální složitosti (exponenciálně závisí na třetí odmocnině délky faktorizovaného čísla). Nic lepšího není na obecné RSA moduly známo.
Bohužel ne-matematici si neuvědomují, co to znamená: konkrétně, že prodloužení délky faktorizovaného čísla o 3 bity znamená nárůst komplexity algoritmu 2×.
Z hlediska laika je 2048 bitů „jenom“ 2× více než 1024 bitů… a že se v tom skrývá 2334 faktor složitosti, to jim nevysvětlíš.
Osobně dávám přednost tomuto příměru: milion má jen dvakrát víc nul než tisícovka, ale za jak dlouho ty dvě hodnoty vyděláš? Bohužel tento příměr funguje jen na lidi, co jsou ochotni myslet, což ne každý je.
Me by stacilo jen proste zasifrovani tgz souboru a nasledne rozsifrovani. Ale bez zadny klicovych serveru, bez nutnosti ukladat si privatni a verejny klic v .gnupg slozce. Pri sifrovani a rozsifrovani bych jen uvedl cestu k sifrovacimu klici a spustil. Lze to nejak takto udelat? Samozrejme privatni klic by byl chranen pres passphraze
1) Predavani hesla pres command-line je zasadni bezpecnostni chyba
2) Symetricke sifrovani jde delat snadno pres gpg, neni treba pouzivat openssl (na heslo se zepta interaktivne):
sifrovani: gpg -c -o soubor-sifrovany soubor-plaintext
desifrovani: gpg -d -o soubor-plaintext soubor-sifrovany
Jo, GPG mam rozchozene jiz nekolik let. Je mi celkem na dve veci, zatim jsem se setkal jen se dvema lidmi, kteri byli schopni pouzit toho, ze jim mohu poslat sve maily zasifrovane a/nebo podepsane. Jeden blbec mi dokonce odepsal, co ze jsem mu to poslal v priloze za virus, ze na to rozhodne nehodla klikat (GPG podpis).
A vetsina lidi, jede na Webmailu, kde se podepisovat moc neda nebo na Utlouku Express, kde se podepisovat moc neda take. Cetl jsem neco o vlekle neschopnosti Utlouku zachovat nepozmenene formatovani tela zpravy, diky cemuz podpis nesedi.
Sifrovat se v Utlouku da, ovsem narazil jsem na nejaky navod, podle ktereho to vypada, ze to pro BFU je moc komplikovane. Integrace GPG s Utloukem se zda ne moc pohodlna.
K tomu si prictete key servery, ktere se mezi sebou sice maji synchronizovat, nicmene nektere tak chronicky necini.
Takze bohuzel, k masovemu rozsireni GPG asi hned tak nedojde.
GPG / PGP je nástroj pro lidi, kteří chápou podstatu ohrožení, a tudíž nebude nikdy příliš rozšířen.
Analogie: v jednom nejmenovaném domě je jen jedna partaj, která má kvalitní bezpečnostní dveře a la NeXT; takové ty, k jejichž překonání je podle atestů potřeba 15–30 minut s rozbrušovačkou. Zbytek jich má papundeklové dveře, které není problém vyrazit ramenem (jednou to tady zvládli hasiči…) nebo oddlabat v tichosti zámek obyčejným dlátkem.
Známý z kriminálky tomuto přístupu říká „nedobrovolní dárci cenností“.
Podobně to funguje i u ochrany čehokoliv jiného, včetně obsahu e-mailů.
> GPG / PGP je nástroj pro lidi, kteří chápou podstatu ohrožení, a tudíž nebude nikdy příliš rozšířen.
Dokud v mailerech nebude snadna, klikaci podpora, BFU se ani nezacne zajimat o to, co to je. Tedy hlavne v Utlouku, ktery ma asi vetsina lidi. A hlavne nejak ve webmailech, kterymi dneska spousta lidi nahrazuje tradicni mailer. Jenze to je trochu problem. Kde skladovat klice, aby se k nim zli hackeri nedostali?
Mě by zajímalo, kde jsou ty vygenerované klíče (soubory) uložené. Takhle jsem si cosi vygeneroval, kmail to evidentně vidí, ale netuším, kde to je, ani nevím, jak ověřit, zda to kmail používá správně. Třeba je mi velmi podezřelé, že mi nabízí „Podepisovací klíč“ a „šifrovací klíč“ tentýž. Přitom z podstaty věci by k podepisování měl používat můj soukromý klíč a k šifrování veřejný klíč protistrany (a jak článek správně píše, měl by přiložit i zprávu zašifrovanou mým veřejným klíčem, abych si ji mohl přečíst i já). Nabídnul mi ale v obou případech klíč se stejným ID a neobtěžuje se mi sdělit, zda jde o veřejný nebo soukromý klíč z páru vygenerovaných klíčů. Prostě klíč 6789ABCD a basta fidli.
Takže někde mám vygenerovaný pár klíčů a nevím kde (tedy já to tuším, nejspíš to bude ~/.gnupg/pubring.gpg a ~/.gnupg/secring.gpg ale to mi nestačí). Kmail mi nabízí cosi pro podepisování a šifrování, ale nevím co, a nevím, jak si ověřit, že to používá správně. Trochu příliš nejistoty na to, že jde o bezpečnostní vychytávku. Chápu, že kmailu se bude věnovat někdy později, ale to, kam a jak klíče byly uloženy, mělo být napsáno už v tomto článku. Konstatování „…, který uvidí všechny aplikace, které…“ je téměř k ničemu.
Za týden už bohužel nebudu nejspíš vědět, co jsem dneska udělal. Autor jistě chce napsat seriál o zajímavé věci (a ono to zajímavé je), ale kromě toho, že mě hezky navnadil, tak mě taky nepříjemně potrápil – mám teď v kompu něco, co bych rád někdy v budoucnu používal, ale nevím, co to je a kde to je. Snadno to tedy může být kompromitováno a já to používat moct nebudu. (Budu si muset vygenerovat nový pár klíčů.)
Jo a ještě bych se přimlouval, aby v seriálu co nejrychleji vysvětlil používání klíčových serverů, neboť ty nejsou klíčové jen kvůli tomu, že na nich jsou uloženy veřejné klíče, ale také kvůli tomu, že bez nich (a vzájemného podepisování klíčů uživateli) by celá ta technologie byla celkem k ničemu.
V diskusi někdo lamentuje nad tím, že podepisování není jednoduché. Divíte se, když i na odborném serveru je uveden příklad, který by obyčejného uživatele naprosto spolehlivě odradil? To není nutně vina autora tohoto článku, ale toho, že GPG není ještě patrně připraveno pro obecné použití. Principiálně je to výborná věc. Chce to ale zapracovat na uživatelské stránce věci. Bohužel. Je opravdu na čase, aby lidi aspoň podepisovali.
To, že podepisování není vůbec zřejmé ani odborníkům, jasně ukazuje příklad problému s podepisováním zpráv v datových schránkách, resp. ověřováním správnosti podpisu po té, co vyprší jeho platnost. Série osvětových článků tedy bude více než vhodná. Bohužel z pohledu tvůrců systému datových schránek přichází s křížkem po funuse.
s asynchr. kryptogr. a celou problematikou jsem se poprve prakticky setkal jiz v dobach W95, a po W98 se to dokonce dalo pouzivat. ovsem nebylo jaksi S KYM to pouzivat. 99% kontaktu odmita jakekoliv zaezpeceni, a svoji neochotu pripustit si rizika racionalizuji matematickou pravdepodobnosti ‚ale me se to nestane, co si na me kdo veme‘, pripadne ‚to by prece v televizi rozmazli‘…
jediny s kym to muzu pouzivat jsou fakt nadsenci z komunity… 10 let to je, a stejne to nikdo nepouziva… achich…;/
tesim se na pokracovani. mozna se moje deti dostanou k mailu ktery nebude seznam nebo jina mrdka pro ktere je i ta nejzakladnejsi bezpecnost neznamou velicinou.
PS:pls noflame abt freemail service…vsichni vime co to je globalne zac…
V naší firmě šifrujeme veškerou komunikaci pomocí GPG. Za nejschůdnější se ukázala kombinace maileru Thunderbird a pluginu Enigmail; dá se využít i tehdy, když protistrana má Windows či Mac, a její použití se dá vysvětlit i naprostému laikovi.
Samozřejmě, zcela blbuvzdorné to není, a už jsem viděl i člověka, který poslal svůj soukromý klíč nešifrovaným mailem…
Kombinace Thunderbird a Enigmail má jiné problémy, a to kompatibilitu verzí. Například takové openSUSE 11.2 všude cpe Thunderbird 3.0.0 beta, který je ještě dost nestabilní. Sehnat příslušnou kompatibilní binárku Enigmailu pro platformu x86_64 není pro koncového uživatele zrovna jednoduché, na stránkách Enigmail projektu ji nenajdete … musíte do openSUSE build service a přidat si repozitář Mozilla beta.
Pak zjistíte, že TB 3 si moc nerozumí s vaší poštou a rádo padá, tak jej downgradujete na TB 2, ale tím přestal být Enigmail kompatibilní, odinstalovat se ze záhadného důvodu nedá, musíte smazat ručně nějaké adresáře v /usr/lib64, abyste se jej zbavili… no legrace, kterou jsem včera strávil asi hodinu a půl. Ale jakmile rozchodíte TB 2.0.0.23 a Enigmail 0.96.99, máte stabilní prostředí.
Pokud chcete opravdu masove podepisovat/sifrovat mailovou komunikaci, tak by jste se spis meli drzet rozsirenejsiho X509. Duvody jsou zrejme:
– na Windowsech ho umi vsichni klienti out-of-box (neni treba nic instalovat, klasicky Outlook umi s temito certifikaty podepisovat/sifrovat uz cca 10 let, Oultook Express pokud vim taky, alternativy typu TheBat! rovnez no problem …)
– na Macintoshi je situace pokud vim obdobna (tim padem mate pokryto pres 90% BFU)
– na Linuxu vas rovnez nic neomezuje (navodu na rozchozeni certifikatu pod muttem, pine, nebo jakymkoli jimym linuxovym MUA se vali na internetu hafo)
Predstava, ze si kvuli vam budou BFU instalovat do sveho Outlooku nejaky pochybny plugin (nebo kupovat za $$$ originalni PGP) je nerealna. Postovniho klienta kvuli tomu taky menit nebudou (ve firme ma naprosta vetsina BFU kombinaci Outlook/Exchange se sdilenymi kalendari, ukoly apod. a od sefa jasny pokyn to takhle pouzivat).
PGP (resp. GPG) je hezka vec, ale prakticky pouzitelna maximalne v mensi uzavrene skupine (vetsinou technicky zdatnejsich) uzivatelu, ktera svoji sanci na masove rozsireni bohuzel davno propasla (uzavreni a zpoplatneni PGP Zimmermanem koncem 90 tych let byla hruba chyba a ani pozdejsi nastup GPG to moc nezachranil).
Nechci nikoho od niceho zrazovat, mit moznost vyberu je jednou z hlavnich myslenek opensource. Nicmene snahu nahradit X509 pomoci PGP v dnesni dobe hodnotim spise jako boj s vetrnymi mlyny (zvlaste kdyz jedinym duvodem je, ze vam hosi z Thawte uz nechteji zadarmo vydavat certifikaty).
X.509 má ten samý problém jako PGP dobrovolně to používá málokdo, jinak se to musí lidem nařídit. A když jim to nařídíte (třeba datové schránky), tak si nikdo z nich nesežene kořenový certifikát důvěryhodným způsobem.
PKI je totiž chiméra. Třeba podle české zákona o elektronickém podpisu mají unijní zahraniční kvalifikované autority stejnou váhu, jako naše tři české. A přitom jejich kořenové veřejné klíče nejsou podepsané žádnou ústřední autoritou (jinak by nebyly kořenové), ale ani se nikdo nesnaží je podepsat křížově (i vnitro pouze vystavuje tři otisky na prostém webu bez podpisu).
Takže zatímco X.509 jsem nucen používat nebezpečným způsobem, PGP si mohu díky síti důvěry přizpůsobit vlastním potřebám. Důvěru totiž nelze nařídit a ti co se o to snaží, tak moc důvěryhodně nepůsobí.
X509 bezne pouziva vetsina velkych organizaci.
Tim, ze do takove organizace vstoupite (jedno zda-li se stanete zamestnancem banky/pojistovny, vojakem nebo treba profesorem na univerzite) vam vznikne povinnost respektovat urcita vnitrni pravidla. Mezi nimiz se zhusta vyskytuje povinnost pouzivat ke sluzebnim ucelum certifikat vydany jejich autoritou. Toto narizeni je zcela legitimni (stejne jako povinnost predlozit sluzebni prukaz, nosit uniformu nebo dodrzovat pracovni dobu).
Rozhodne si nemyslim, ze by toto „narizeni duvery“ nejak snizovalo duveryhodnost organizace. Urcite je prijatelnejsi X509 certifikat podepsany CA generalniho stabu, nez PGP klic podepsany napdorucikem Bramborou a tremi neznamymi dustojniky od vedlejsi roty :-).
Nehlede na to, ze X509 certifikaty mohu nacpat na cipove karty, mohu vynutit jejich zneplatneni pomoci CRL, o casovych razitkach a podobnych vecech ani nemluve. Co mi v tomto smeru nabizi PGP … ?
Jako priklad masoveho pouziti X509 (mimo uzavreny svet te ci one organizace) je mozno uvest pristup na jakykoli vetsi zabezpeceny web. At uz se jedna o elektornicke bankovnictvi, e-shop nebo cokoli jineho. Korenovy certifikat budete mit v tomto pripade nejspise predinstalovany ve svem prohlizeci, ktery jste ziskal duveryhodnym zpusobem (a pokud jste opravdu paranoidni, tak vam nic nebrani si ten klic Verisignu overit treba telefonicky :-).
To, ze kokoti z ceske posty nejsou schopni podepsat svuj web s datovymi schrankami nejakym rozumnym certifikatem nebo prijatelnym zpusobem distribuovat korenovy certifikat sve vlastni CA, s tim nema nic spolecneho.
> Pokud chcete opravdu masove podepisovat/sifrovat mailovou komunikaci, tak by jste se spis meli drzet rozsirenejsiho X509.
Pochybuju, ze X509 je v oblasti e-mailu rozsirenejsi. Zatim jsem dostal e-maily podepsane podle OpenPGP od desitek (a mozna i stovek) neznamych lidi, zatimco e-maily podepsane podle X509 tak od jednotek.
Jak je to prosim s „kompatibilitou“ techto dvouch metod/technologii. Chapu, ze kazda zije ve vlastnim svete, ale co bych se chtel zeptat je, zda je mozne pokud mam od nejake certifikacni autority podepsanej osobni certifikat (openssl), zda je mozne ho pouzit k sifrovani pomoci GPG. Jestli spravne chapu tak ne a potrebuju teda mit oboji public/private klice od GPG i OpenSSL podle toho kdy chci jakej v ktere aplikaci pouzit. Nebo lze to nejak pouzit ve smeru OpenSSL → GPG ?
Chapete to spravne.
Pokud chcete pouzivat obe technologie, musite mi dva pary klicu. Jeden pro PGP/GPG podepsany (z hlediska prijemce) duveryhodnymi osobami, druhy pro X509 podepsany (prijemcem uznavanou) certifikacni autoritou.
Jedine co je spolecne je fakt, ze muzete oboji obslouhovat jedinym programem (typicky napriklad pine/mutt na Linuxu ci balikem typu PGP Desktop na Windowsech). Muzete tedy jedne mnozine uzivatelu posilat podepsane/sifrovane maily na bazi PGP/GPG a drune (disjunktni) mnozine uzivatelu na bazi X509. Otazkou zustava, zda-li je to vyhoda nebo spis komplikace …