Proč to nestačí?
Protože tím můžete vyloučit některá rizika, ale ne všechna. Zveřejnění kódu povede k tomu (pokud bude vše v pořádku), že bude ověřitelné, že nikdo po cestě (a ani provozovatel) se nedostanou k obsahu komunikace, ani k metadatům.
Co zůstane dál na důvěře "ke značce" je to, jak Threema zachází se zbytkem (meta)data, které k dispozici má a musí mít.
Názor: v praxi to stejně nikdo nepodrobí auditu. Je to nákladnější, než si vytvořit vlastní způsob chráněné komunikace (včetně té mimoelektronické). Ten, kdo by dal velké peníze do auditu, těžko tím bude chtít podporovat další komerční aktivity Threemy. Celé je to převážně marketingový krok, který má vyvolat snowballing mezi geeky a tím k šíření jména Threemy.
Nestaci to napriklad, protoze
- aplikace zecne praskat az po mesici pouzivani, ale nekdo ji monitoroval jen po dobu tydne
- data schovava steganograficky, nez je posle
- u krypta prakticky nepoznas z komunikace, ze je vse OK, je to hodne tezke i s kodem
- je rada vedlejsich kanalu, ktere takhle nepoznas
Použití steganografie u opensource klienta je zjistitelné. Kdyby steganograficky přidával data server, odhalí se to porovnáním toho co bylo odesláno a jinde přijato.
To co se odhalit nedá, je co vše si u sebe nechává server a jestli to bude možné spárovat s konkrétním uživatelem, tudíž se soukromí ztrácí.
Kdyby steganograficky přidával data server, odhalí se to porovnáním toho co bylo odesláno a jinde přijato.
Dovolím si nesouhlasit. Za prvé, mezi serverem a klientem (asi) probíhá komunikace, která neputuje dál - např. operace s uživatelskými účty, předávání statusů, ... Za druhé, střípek informace může být doručen i druhé straně, ale pokud neví, jak ho poskládat, dost pravděpodobně si nikdo ničeho nevšimne (musel byste udělat analýzu, že opravdu každý předaný bit má svoji vysvětlitelnou hodnotu a zbytek považovat za podezřelé). A za třetí, informace se dá předávat i v nižších vrstvách komunikace. Možná už ne s takovou spolehlivostí (mohou je pozměnit routery / firewally po cestě), ale stále to je existentní cesta. Už jen do obyčejného timestampu se dá vpravit střípek informace - do řádu nanosekund uložíte informaci pomocí modulo - a nikdo si ničeho nepovšimne.
Asi by se daly vymyslet miliony způsobů, které nejsou odhalitelné jinak, než náhodou nebo studiem zdrojového kódu.
Tak isto ako sa testuju vsteky aplikacie - napriklad cez Burp proxy.
Zatial co pri zdrojakoch sa stava, ze to ani neskompilujes, mozes mat v store nieco co nie je zo zdrojakov (nieco napriklad pridali), a to sa nemusi tykat len zdrojakov, ale kludne nejakych binarnych balickov, tretostrannych kniznic, binarnych blobov,...
Takze z hladicka bezpecnosti mat otvorene zdrojaky je asi ako mat nalepsku bio na potravinach, je to sice pekne, ale v praxy na nic.
V praxy je vzdy lepsie testovat na bezpecnost samotne binarky, ako zdrojaky
Jak prosím z předložené binárky otestujete rizika? Nějak ji dekompilujete a začnete vytipovávat, jak testovat?
Mám dojem, že se Vám plete aplikační testování (tj. testování funkčnosti) a bezpečnostní audit. Při testování funkčnosti zkoušíte hraniční situace, které lze ještě jakš takš z binárky dovodit (a zdrojáky jsou k tomu jen bonusem navíc). U bezpečnostního testování už není takový postup dobře realizovatelný - už jen např. jakost užití jakož i jakost samotného RNG v podstatě nevyčtete jinak, než z kódu, nebo opravdu rozsáhlou empirií. Rozsah odesílaných metadat také nezjistíte ani na proxováním, protože mohou být odesílána náhodně či velmi řídce nebo a k tomu rozsetá (a na druhé straně poskládaná). Opět, z binárky to nikdy s dostatečnou spolehlivostí nevyloučíte.
Zkrátka, pokud máte k dispozici zdroják a reprodukovatelné sestavení, vyhnete se kompletně procesu dekompilace / deobfuskace a vysoké míře empirie.