Open-source a backdoory
Kdykoliv se někde objeví článek o komerčním šifrovacím nástroji, docela jistě se u něj objeví aspoň jeden komentář, že u programu s uzavřeným kódem nikdo neví, jaká skrytá dvířka do něj programátor umístil. A hned se objeví reference na TrueCrypt, který je zdarma, umí to samé, a „díky tomu, že je to open-source, si každý může ověřit, že je čistý“. Problém je v tom, že toto tvrzení je nepravdivé. Dokonce hned na dvou úrovních: Není pravda, že v open source programu nelze úspěšně skrýt backdoor, a také není pravda, že u open-source programu má uživatel větší jistotu. Speciálně u TrueCryptu to platí dvojnásob.
„V open-source nemůže být backdoor“
Logika tohoto tvrzení je jasná: Když je k dispozici zdroják, je relativně snadné si ověřit, co se v tom zdrojovém kódu nachází (relativně vůči zkoumání zkompilovaného strojového kódu). Což je do jisté míry pravda, aspoň v obecném případě (u šifrovacích programů je to složitější, tam do hry vstupují ještě další ohledy, ke kterým se dostanu). Ale předpokládá to, že jsem ten zdrojový kód důkladně prozkoumal (já nebo někdo, komu důvěřuji), že jsem si z něj zkompiloval binární program a že oba tyto kroky opakuji pro každou další aktualizaci toho programu. Pokud kterýkoliv tento krok vynechám, nevím o bezpečnosti toho programu nic:
-
Vynechám zkoumání zdrojáku: O tom, co v kódu je nebo není, nic nevím. Spoléhám se na to, že ten zdroják někdo dostatečně dobrý prozkoumal (což není jisté – přesně to samé si mohou říct i všichni ostatní uživatelé a kód nakonec neprozkoumá nikdo). A jistě uznáte, že argument „kód lze prozkoumat, tudíž kód je bezpečný“ poněkud postrádá na přesvědčivosti.
-
Vynechám vlastní kompilaci: O tom, co je v běžícím programu, nic nevím. Spoléhám se na to, že ten program vznikl kompilací toho zdrojáku, který jsem prozkoumal, ale nemám pro to nejmenší důkaz. Pokud očekávám, že autor do svého programu zabudoval backdoor, proč bych mu měl důvěřovat, že binární verze programu opravdu odpovídá zdrojovému kódu?
-
Vynechám ověřování dalších verzí: Opět, o tom, co běží v nové verzi, nevím vůbec nic. Spoléhám se na to, že autor backdoor dodatečně nepřidal.
Mimochodem, při ověřování té nové verze nestačí jenom projet změny mezi soubory. Jak ví každý, kdo programoval nějakou rozsáhlejší aplikaci, zdánlivě neškodná změna na jednom místě se může docela dobře projevit jako kritická chyba na místě jiném. A nikde není řečeno, že ta zavlečená kritická chyba musí být náhodná a neúmyslná…
V případě šifrovacích nástrojů je to ještě složitější v tom, že se v nich spojují dvě vysoce specializované profese a ten, kdo kód zkoumá, musí být velmi dobrý v obou současně (naproti tomu na skrytí backdooru stačí dva lidé, kteří jsou každý dobrý jen v tom svém oboru). Potíž je v tom, že „backdoor“ vůbec nemusí být jenom něco tak profláknutého jako ukládání zapsaných hesel do souboru nebo jejich odesílání někam na internet, ale může jít o dvířka mnohem a mnohem skrytější – úplně klidně může jít například o nenápadné narušení bezpečnosti algoritmu, na které ani skvělý programátor vůbec nemusí přijít, prostě proto, že to narušení je úplně mimo jeho specializaci. Nádherně to předvedl The Underhanded C Contest v roce 2007, jehož cílem bylo implementovat skrytá dvířka, která nebudou vidět. Jednou z hodnocených vlastností byla přitom délka programu (čím kratší, tím lepší – skrýt škodlivý kód do mnoha MB sena dokáže každý, ale udělat totéž na pár řádcích?). Jestli věříte v nemožnost umístit backdoor do open source, zkuste si odhalit slabiny některých nabízených prográmků – třeba v téhle části implementace RC4:
#define TOBYTE(x) (x) & 255 #define SWAP(x,y) do { x^=y; y^=x; x^=y; } while (0) static unsigned char A[256]; static int i=0, j=0; void init(char *passphrase) { int passlen = strlen(passphrase); for (i=0; i<256; i++) A[i] = i; for (i=0; i<256; i++) { j = TOBYTE(j + A[TOBYTE(i)] + passphrase[j % passlen]); SWAP(A[TOBYTE(i)], A[j]); } i = 0; j = 0; } unsigned char encrypt_one_byte(unsigned char c) { int k; i = TOBYTE(i+1); j = TOBYTE(j + A[i]); SWAP(A[i], A[j]); k = TOBYTE(A[i] + A[j]); return c ^ A[k]; }
Mimochodem, tady víte, že je nějaká slabina. Dokázali byste obdobnou najít v programu mnohem větším, u kterého nevíte, jestli tam je nebo není?
Připouštím, možná to bylo příliš jednoduché. Zkusíme něco složitějšího a praktičtějšího (originál, nezkažený mojí interpretací: The Strange Story of Dual_EC_DRBG): Nesmírně důležitou součástí každého šifrovacího algoritmu je generátor náhodných čísel – mimo jiné proto, že náhodná čísla slouží k vygenerování klíče. V roce 2007 vydal americký NIST dokument, ve kterém popisuje několik generátorů náhodných čísel postavených na celkem dobře prozkoumaných a prověřených kryptografických základech. Jeden z nich vykazuje několik zajímavých vlastností, mimo jiné silnou podporu ze strany NSA. Ale to nejzajímavější je, že v něm existuje slabina, kterou lze označit jako backdoor – kryptologové Dan Shumow a Niels Ferguson (podílel se například na algoritmu Twofish a na Microsoftím Bitlockeru) ukázali, že konstanty v algoritmu použité mají vztah k jiným konstantám, s pomocí kterých lze předvídat generovanou posloupnost už se znalostí 32 předchozích členů posloupnosti. Potíž je v tom, že nikdo neví, jaká ta odemykací konstanta je a jestli ji NSA má. Zrovna tak dobře může jít prostě o chybu v návrhu jako o úmyslný backdoor.
V tomto případě došlo k odhalení docela rychle – mimo jiné i proto, že chyba/backdoor byla přímo součástí algoritmu. Je otázka, jestli by byla nalezena i v případě, že by příslušný generátor nebyl k dispozici jako algoritmus ale jen jako zdrojový kód, speciálně navržený tak, aby slabinu zakryl. V takovém případě by na ni mohl přijít jen špičkový programátor a kryptolog v jedné osobě (nepravděpodobné) nebo jeden špičkový programátor a jeden špičkový kryptolog (ještě nepravděpodobnější, ve vzájemné komunikaci by se důmyslně skrytý backdoor snadno ztratil – programátor nedostatečně odhadne význam zdánlivé drobnosti, neřekne o ní kryptologovi a ten tudíž neodhalí zásadní slabinu).
„V open-source má člověk větší jistotu“
Přesnější by bylo říct, že do open-source se může důkladně podívat víc lidí. Jak už ale bylo naznačeno v předchozí kapitole, to nemusí nutně vést k odhalení chyby. Ale stejně, přinejhorším bude open-source na stejné úrovni jako closed-source, ne?
Ne nezbytně. Uvažujme například TrueCrypt (open-source, freeware) a některou z komerčních šifrovacích aplikací. Co by se stalo, kdyby do některé z nich jeden z vývojářů zabudoval backdoor a někdo na to přišel? V případě komerční aplikace má dotyčná firma problém – okamžitě přijde o důvěru zákazníků, takže ztratí odbyt (a příjmy). A i kdyby tohle přežila, což vůbec není jisté, musí čelit ještě dalším hrozbám, například soudním sporům (nepochybuji, že by ji někdo zažaloval o náhradu škody nebo za klamavou reklamu nebo kdo ví za co). Její zaměstnanci by pravděpodobně přišli o živobytí – programátoři snad jen na čas, kryptlogové asi navždy. Budou to chtít riskovat jenom proto, že si jejich management přeje sbírat tajná data?
TrueCrypt by na tom v této hypotetické situaci byl podstatně lépe. Sice také ztratí důvěru, ale jeho autoři mají vlastní na TrueCryptu nezávislé zdroje obživy, takže se jich to přímo nedotkne. A hlavně – nikdo neví, kdo je autorem TrueCryptu. Kdyby na to přišlo a TrueCrypt skutečně byl zdiskreditován, jeho autora se to nedotkne. Klidně může udělat pár změn a pod novým názvem vypustit „fork TrueCryptu, ze kterého byly odstraněny všechny backdoory“.
Můžete namítnout, že to je problém TrueCryptu a netýká se ostatních programů. Pokud jde o bezpečnost autorů, souhlasím. Ale skutečnost, že komerční firma má ve svém produktu investované konkrétní peníze, o které by odhalením backdooru přišla, platí univerzálně.
Rád bych ale v této souvislosti řekl, že nemám důvod TrueCryptu nevěřit. Nevím o ničem, co by i třeba jen naznačovalo, že TrueCrypt není tím, čím se snaží být – totiž špičkovým a bezpečným šifrovacím nástrojem. Naopak existují důvody pro doměnku, že TrueCrypt bezpečný je. Mimo jiné známý český kryptolog Vlastimil Klíma svého času TrueCrypt prověřil a potvrdil, že TrueCrypt neobsahuje zadní vrátka. Potíž je ovšem v bodech 2 a 3 části o backdoorech v open-source a také v tom, že jakkoliv je V. Klíma uznávaným kryptologem, nejsem si úplně jistý jeho schopnostmi programátora – a zejména si nejsem jistý tím, jestli se zaměřil i na záludně skryté backdoory. V článku o tom není ani slovo, což může znamenat, že to udělal a nic nenašel, ale také že to neudělal.
Celý předchozí text byl zaměřen na vyvrácení pochybného argumentu o bezpečnosti open source. TrueCrypt byl zmíněn jako konkrétní příklad, v čem nemusí být open-source tou odpovědí, za kterou ho všichni považují. Zamyšlení nad backdoory v TrueCryptu jsou z mé strany čirou, ničím nepodloženou spekulací o tom, že kdyby vývojáři TrueCryptu chtěli do svého programu zabudovat backdoor, tak by se jim to mohlo podařit, a i kdyby na to někdo přišel, nemělo by to pro ně žádné nebezpečné důsledky.
Vyborny clanok!
kena: A nebyl bych překvapen, kdyby Heartbleed byl čistokrevným backdoorem a ne jen chybou, které si nikdo nevšiml. Ale to se asi s jistotou nikdy nedozvíme.
Událost posledních dní zcela potvrzující tenhle článek: http://en.wikipedia.org/wiki/Heartbleed_bug
Chyba v OpenSSL umožňující číst hesla a privátní klíče, nalezená náhodně až po 2 letech existence.
díky za přínosný článek o pohledu na bezpečnost free-source
*“moznost videt, co program dela“: „moznost videt, co program dela (ve forme citelnejsi, nez zkompilovana binarka)“
„open-source sám o sobě žádnou jistotu nedává“
Open-source nedava jistotu. Open-source dava moznosti.
V tomto pripade zejmena moznost videt, co program dela.
To, na jake urovni jsou vedomosti/schopnosti cloveka ohodnotit program do jiste „hloubky“ – a tak odhalit jeho nedostatky v dane „rovine“ – uz je otazka odlisna.
V praxi „absolutni bezpecnost“ neexistuje. Existuji jen ruzne techniky zabezpeceni RELATIVNI, s ruznymi „naklady“ na jejich nasazeni, a ruznymi naklady na potencialni prelomeni.
pepak: Určitě s Tebou souhlasím na té obecné rovnině opensource, jež jsme již diskutovali. Přispěl jsem zde do diskuze, abych svými níže uvedenými poznatky případně obohatil čtenáře, zejména ty z méně odborných kruhů v daném tématu, o další zkušennosti a rozšířil tak informace v článku uvedené. Snad se trochu podařilo. Jinak díky za Tvé postřehy a názory.
Martin Strejc: Můžeš mít pravdu, ale není to relevantní argument. Nehodnotím, jestli je bezpečnější open-source nebo closed-source. Zabývám se tím, že open-source sám o sobě žádnou jistotu nedává, a že stejně jako existují specifické důvody, které nahrávají bezpečnosti open-source, jsou i specifické důvody, které nahrávají bezpečnosti closed-source. Nakolik se ten který argument promítá do konkrétní situace konkrétního čtenáře není moje věc.
Rozdhoně beru, že opensource NENÍ absolutní ochrana před backdoory. Vedle toho bych si však směle dovolil postavit tvrzení, že absolutní ochrana před backdoory neexistuje a ani absolutní ochrana jako taková neexistuje (ať již šifrování, firewall, antivir, cokoliv). Přesto na základě různých statistik a výzkumů se ukazuje, že opensource software je na tom s bezpečnostní dobře. Platí až při rozsáhlejší komunitě vývojářů a uživatelů, kde se již statisticky eliminuje to, že na zanesenou chybu (ať již chybu nebo backdoor) opravdu někdo příjde, respektive se tím vůbec zabývá.
Z výše uvedeného se zapojuji do této diskuze, neboť bych rád upozornil ty méně zkušené uživatele, kteří článek četli, že článek posktyuje reálně možné informace, z hlediska bezpečnosti se však jedná o dost extrémní záležitosti, které běžný uživatel (nikoliv odborník na software, bezpečnost apod.) bude hodnotit.
Bohužel na závěr musím konstatovat, že jsem se několikrát setkal s komerčními produkty, kde se do ostré verze běžně dostával administátorský přístup s pevným účtem admin/admin pro hlavního správce, či jinými „triky“ vývojářu při ladění aplikací. Netřeba dodávat, že často se jednalo o funkční instance i celkem drahého software. Ať již byla snaha firem si udržet pověst jakoukoliv, někteří nezodpovědní vývojáři takto smýšlí, a někteří si tímto způsobem nechávají sami zadní vrátka i v některých velkých firmách 🙁
Tedy z toho asi plyne to, že opensource není ochrana před backdoory, leč komerční software také ne. Jediná opravdová ochrana před backdoory je, že si software napíšu sám či nechám na svoji verzi programu provést bezpečnostní audit nějakou renomovanou firmou a v zápětí vypnu aktualizace, aby nějaký backdoor nemohl být v příští verzi. Je toto však vůbec reálné? Jaká musím mít data, aby se mi již tento způsob bezpečnosti vyplatil?
Martin Strejc: Článek je o tom, že open-source není absolutně žádná ochrana proti backdoorům, a jsou popisovány specifické postupy, jak by se to zrovna u TrueCryptu dalo zařídit. Nikde nepíšu, že TrueCrypt backdoor obsahuje, polemizuji ovšem s běžným (a chybným) tvrzením, že neobsahuje, protože má otevřený zdroják a někdo by na to přišel.
Článek opravdu hodně obecně polemizuje nad bezpečností Open-source jako takového, možná zbytečně zaměřeno specificky na TrueCrypt, kterýho se zmíněné potenciální problémy mohou týkat na spíše hypotetické rovině. Krom toho spousta programátorů si dle výzkumů nechává zadní vrátka i ve velkých firmách (potažmo uzavřeném sw). Netuším jak dobrý musí být bezpečnostní audit, aby něco takového v software (ať již opensource či uzavřeném kódu) odhalil a podobně. Věřím tomu, že speciální u šifrovacích programů, kde do hry vstupuje jak matematika, tak programovací postupy, je nalezní takovéto díry a rozpoznání od běžného „bugu“ velmi obtížné. Tedy proto mi připadá výše napsaný článek až příliš skeptický vůči TrueCryptu, byť jako jen představiteli jednoho z kategorie těchto programů.
chmod 5777: Ne, to jsi článek pochopil špatně. Snažil jsem se tam vyjádřit, že i když bude zdroják studovat odborník a specificky hledat backdoory, tak je nedokáže najít, pokud jsou dobře udělané.
ad Apple) kdyby se neco naslo u HP, tak by proste Compaq koupil HP a ne naopak. Realne by to vyslo na stejno, jenom by mela firma novy logo a udelalo by se par jinych ucetnich operaci. Podobnych „zamernych naruseni bezpecnosti“ bylo povicero (i umyslna moznost „vzdalene administrace“ pomoci neodstranitelneho a skryteho uctu) a nevim o zadne situaci, kdy by to skoncilo likvidaci firmy. Maximalne vyhazovem par „odpovednych“ lidi „novym“ cistym managementem. Nechci je tu rozebirat, protoze se nikdy k nicemu nikdo neprizna (slo o zapomenuty ucet z vyvoje, testovani, etc.), ale Apple je priklad o kterem vi vsichni a v tomhle bohuzel neni jediny. Vzdycky se to zasolicha tak, ze jde o zcela zpecifickou situaci, kterou nikdo realne nezneuzil, tak co.
ad Jednoduchost) ale u closed source nemam k dispozici zdrojaky. Tudiz u open source muzu pouzit neco navic – neco, do ceho prumerne inteligentni programator nikdy nic zaskodnickyho cpat nebude.
ad Nuda) popravde nic takovyho sem v clanku nenasel. Ja pochopil clanek tak, ze kdyz bude _jeden_ odbornik overovat zdrojaky, tak zamaskovany back door nenajde. S tim nelze nesouhlasit. Ovsem pokud se bavime o tisicich (nebo milionech) nahodnych „prozkoumani“ – tak presne tohle je zpusob, jak prichazi na svetlo bezpecnostni trhliny. Ze nakyho znudenyho brejlovce napadne nakonfigurovat neco zcela silenym zpusobem a pak zkusit „co to udela“.
ad backdoor) yup ;-D nicmene pres 90 % utoku se dela pomoci social engineering takze, vetsina uzivatelu (i tech vzdelanych) by se zkutecne mela spis zamerit na to, jakym zpusobem program pouzivaji, nez na mizivou pravdepodobnost, ze ve zdrojacich je backdoor. Nebal bych se tvrdit, ze ta pravdeposobnost bude podobna pravdepodobnosti, ze do zkompilovanyho programu prida backdoor jejich upiratena verze visual studia 😉
chmod 5777: Apple bych do toho nemíchal, protože za prvé tam byl úplně jiný charakter provinění (porušení soukromí, ne backdoor, což v odbě Facebooku a spol. už skoro nikoho nevzruší) a za druhé Apple má se svými uživateli naprosto specifický a řekl bych až unikátní režim bytí, podobný spíš vztahu církve a věřícího než výrobce a zákazníka. Nenapadá mě v IT jiná firma, které by toho prošlo tolik, co Applu – ostatně, představte si, jak by dopadl třeba Eset nebo Avira, kdyby se prokázalo, že kdovíjak dlouho vyráběli a šířili viry, aby mohli prodávat antivirus.
Ad logika jednoduchosti: To ovšem celkem nijak nesouvisí s tím, jestli je nebo není k dispozici zdrojový kód. Sám říkáte – nebudu backdoor cpát do zdrojáku, ale jen do binárky. To můžu stejně dobře udělat u otevřeného i u uzavřeného kódu. Já v článku upozorňuji na něco jiného – že když to udělám dobře, tak na to nikdo nepřijde ani v jednom případě.
Ad logika nudy: To je sice hezké, ale jádro argumentace ve článku je, že takovéhle prozkoumání kódu žádný rozumný backdoor nenajde, tudíž je z hlediska bezpečnosti open-source softwaru bezcenné.
Ad „pokud dotyčnému nevěřím, tak si program sám zkompiluju“: To nepochybně udělat můžu. Akorát mi to nijak nepomůže. Důvody jsem podrobně popsal.
Ad „Nejvíc backdoorů je mezi klávesnicí a židlí“: O tom není pochyb, pokud použijeme dostatečně pružnou definici backdooru 🙂
zacnu odzadu:
predne ze firma zadnou povest neriskuje dokazal Apple, kdyz do svych mobilu namontoval ukladani pozice
V diskusich vzycky obhajuju bezpecnost open source a vzdycky z toho vyleze tohle, takze se to pokusim shrnout:
LOGIKA JEDNODUCHOSTI: pokud bude chtit autor dat nekam back door, tak je vrazi do binarni verze. Je to jednoducha logika: pokud si muj program bude stahovat milion opic a 10 geniu, budu se neco snazit podstrkovat tem opicim (notabene v tezko citelnem formatu), nebo pocitacovym genium (notabene v plain textu)? Vrazim to do binarky. Tudiz uz z tohoto duvodu budou zdrojaky cisty (rozhodne bezpecnejsi, nez stazeni binarniho kodu).
LOGIKA NUDY: neustale se argumentuje, ze lidi jsou lini a nikdo ty zdrojaky zkoumat nebude. Nevim, kde ostatni zijou, ale ja se neustale setkavam s presne opacnym postupem. Kdy nekdo dela projekt do skoly, tak si veme odnekud kus kodu a rozebere ho. Nebo primo napise seminarku „Implementace spravy hesel v progamu XYZ“. Ja sam jsem se takhle naucil jeden moc zajimavej postup. Takze ne, asi nikdo neprozkoumava cely zdrojaky TrueCrypt, ale stoprocentne hromada lidi si bud nahodne nebo cilove vybere kus zdrojaku a ten si procte, nebo rovnou prozkouma a popise. Ze to nikde nezverejni neznamena, ze to nedelaj. Pokud budou tyto pokusy studentu dostatecne a zcela nahodne, pak se ciste statisticky na danou chybu prijde.
A ano, binarni kody jsou tak bezpecne, jak duveryhodny je ten, kdo je podepsal. Pokud dotycnemu neverim, tak si udelam vlastni kompilaci. Je to pracne a bezpecne. Nejdrazsi veci k dostani jsou svoboda a bezpecnost. Jsou drahe a nejsou pro kazdeho. Pokud sifrujete komunikaci s milenkou, tak bohate staci binarky.
A pokud po vas jde NSA, tak pouzijte rovnou sekeru, protoze jsou udajne schopni obnovit data i po vicenasobnym prepisu nahodnymi cisly.
Pokud se uz bavime o US a NSA, tak v TCSEC (to je ta „tlusta Oranzova Kniha“ znama z filmu Hackers) je podrobne popsano jak se maji data likvidovat, aby je neslo obnovit. Pro kazdou dalsi uroven je popsan dodatecny postup. Pro nejvyssi levely (nevim prsne odkud) pozaduje nekolikanasobny prepis a nasledne zniceni media.
Pokud myslite, ze na hardisku mate data v hodnote, ktera by ospravedlnila jeho prevoz do Langley a naslednou analyzu, tak byste nepochybne taky meli mit vsechno vlastni vcetne OS.
V opacnym pripade si zkompilujte open source a zamerte se na to mezi zidli a klavesnici, protoze tam byva ukryto nejvice back dooru ;-D
Pro KeePass (a podobné programy) samozřejmě platí to samé, co jsem tady demonstroval na TrueCryptu.
Amen !
Totozne myslenky a zavery jsem nezavisle ucinil pred mesicem v pripade KeePass, ktery je z pohledu zneuziti daleko vetsi lakadlo nez TrueCrypt (takovy TrueCrypt HDD je pristupny pouze lokalne, kdezto sluzby chranene hesly v KeePass jsou casto pristupne na Internetu).
Nevím, jsem k tomu spíš skeptický. Dvojnásobné šifrování může docela dobře vést i k zeslabení šifry jako takové, protože algoritmy mohou působit proti sobě. Zatím nevím o žádném seriozním výzkumu, který by se zabýval interakcemi mezi algoritmy.
„Pokud opravdu o něco jde“, soustředil bych se spíš na jiné způsoby řešení: Asi hlavně na vlastní implementaci podle referenčních algoritmů (algoritmy jsou velmi dobře prozkoumané a šance na backdoor v nich je minimální, i když v článku je popsán i případ, kdy k tomu zřejmě došlo; naproti tomu do implementace algoritmu se dá backdoor schovat celkem snadno). V nouzi největší bych si zaplatil pár expertů, aby mi nějakou konkrétní verzi nezávisle na sobě prozkoumali a tu prozkoumanou verzi pak budu, i při vědomí, že se všichni experti mohli mýlit, používat.
Když chci větší bezpečí, není lepší zkombinovat několik programů (tedy šifrovat znovu již zašifrovaný obsah něčím jiným)? Sice zvýším např. dvakrát výpočetní náročnost, ale na druhou stranu pravděpodobnost, že někdo vnese backdoor do více různých programů (zvláště uzavřených) je mnohanásobně menší. Ideální by ještě bylo, kdyby pracovaly na různém principu – s různými algoritmy, aby v případě, že se najde chyba v jednom algoritmu, nebyla bezpečnost ohrožena.
Cena dvoj (nebo obecně konstantního) násobku nákladů mi nepřijde vzhledem k přínosům velká, pokud opravdu o něco jde (pokud nejde, tak se tím nemá smysl zabývat).
Dan Brown je asi tak spolehlivý zdroj o bezpečnosti, jako Michael Moore o politice. Což nevylučuje, že v tomto případě má zrovna shodou okolností pravdu – možné to je.
Nedivil bych se, kdyby NSA tu konstantu někde měla (Dan Brown: Digitální pevnost; některé narážky jsou docela jasné).
Krásně napsané, moc se mi to líbí. A musím souhlasit, bohužel v zásadě se vším. Já jsem skutečně kdysi zkoumal, jak je z kryptografického hlediska udělán Truecrypt. Tam jsem shledal profesionalitu, čistotu provedení a žádná zadní vrátka. Mám i nějaké zkušenosti s programováním, ale bohužel nemůžu ručit za to, že ty funkce nemají programátorská zadní vrátka. Tady naprosto souhlasím s autorem. I kdybych moc rád i jako uživatel Truecryptu, aby tam programátorská zadní vrátka nebyla, nevím to a pouze věřím, že nejsou (víra není bezpečnostní politika, nic jiného mi ale nezbývá). Pokud se najde někdo, kdo řekne, že v celém programovém kódu Truecryptu nejsou žádná zadní vrátka, tak mu na druhou stranu věřit asi nebudu, nezlobte se, to prostě stoprocentně nejde. Pokud snad něco co jsem řekl nebo napsal vyznělo tak, že jsem právě to udělal, tak to by bylo hluboké nedorozumnění. Je mi líto, ale jistota v tomhle složitém světě je pouze negativní.
Autorovi přeju hodně takových článků,
Vlastimil Klíma
a) Což o to. Pokud nějaká význačná autorita prohlásí, že kód prověřila, byl bych ochoten jí to věřit – nevěřím, že by někdo riskoval svoje jméno v situaci, kdy stejně dobře mohl neříct nic a být v klidu. Spíš mě zneklidňuje ten problém, že v této oblasti se stýkají vysoce specializované obory a těžko se najde někdo, kdo by byl špičkovým odborníkem v obou z nich – prohlášení kryptologa může být bezcenné, pokud bylo slabé místo třeba i neúmyslně zakomponováno do programu a ne do algoritmu nebo principů.
b) To nevíš.
Pěkně napsané, děkuji. Přidal bych ještě jedno hledisko – i když někdo prohlásí, že zkontroloval příslušné zdrojáky a jsou v pořádku, tak:
a) jak vím, že nelže? Zase by to musel být někdo, kdo na tom má zavislou svoji profesionální pověst, tedy ne kdokoli, ale světově významná osobnost v oboru
b) jak vím, že stahuji identickou verzi zdrojáku, kterou někdo kontroloval? Dneska se dá zfalšovat i hash…
Tyto dva body IMHO odkazují všechno s výjimkou vlastní kontroly zdrojáku a vlastní kompilace do říše pohádek, tedy „jedna paní povídala, že je to bezpečné“.