Google vydal kryptografickou multiplatformní knihovnu Tink pod licencí Apache. Knihovna by měla usnadnit jednoduché a správné zacházení s kryptografií.
Knihovna staví na Java Cryptography Architecture, BoringSSL a dalších open-source projektech. Zatím podporuje Javu, C++ a Obj-C. Zdrojové kódy jsou dostupné na GitHubu.
(zdroj: phoronix)
a opakovaně se prokazuje, že open source v krypto je nutná, ale nikoliv dostačující podmínka. Platí tady stejně to, že musím věřit autorům a musím věřit auditorům.
Za tuhle knihovnu Google neručí, pouze dal zaměstnancům prostor. Stojí za ní třeba Daniel Bleichenbacher, který se 20 let věnuje SSL a jeho zranitelnostem.
"opakovaně se prokazuje, že open source v krypto je nutná, ale nikoliv dostačující podmínka"
Kdyby jen nutna, je to naprosta NEZBYTNOST pro jakekoliv crypto, na cemz se shoduji VSICHNI co se sifrovanim zabyvaji- pouzivat na crypto nejakej proprietarni blackbox muze jen blazen.....
Ovsem ani verejnej kod neni zarukou niceho, tim spise ze lidi z crypto komunity sami rikavaji "getting crypto right is extremely difficult"......
viz. https://www.tripwire.com/state-of-security/latest-security-news/nist-abandons-cryptography-algorithm-in-wake-of-nsa-backdoor-concerns/
V tomhle interview
https://twit.tv/shows/triangulation/episodes/352?autostart=false
napr Phil Zimmerman (autor PGP a sifrovaneho black-phone) priznava ze v poho zvlada a/symetricky crypto, ale "akademic papers about elliptic curve cryptography" mu hlava moc nebere.....
A jak snadny je neco podelat ve VPN o tom mluvi tady
https://twit.tv/shows/floss-weekly/episodes/468
pennetration tester/hacker Jason Donenfeld - vyvojar WireGuard VPN -o ktery jsem nejen ja presvedcenej ze to bude prulom, viz.
Linus Torvalds Is Hoping WireGuard Will Be Merged Sooner Rather Than Later
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Likes-WireGuard
https://phoronix.com/scan.php?page=news_item&px=Zinc-New-Linux-Crypto-API
PS: mozna by nebylo od vei se znovu poradne podivat na kod SE Linux kterej je v kazdym Androidu, protoze si dobre pamatuju ze jsem nejakejch 8-10 zpatky poslouchal interview s clovekem kterej "krome jineho delal pro NSA" a ten primo tvrdil ze je ve skupine ktera ten kod pise....... Na spoustu otazek nemohl/nechtel odpovedet, takze tezko rict nakolik NSA mela prsty v tom kodu, nebo platila jen jeho vyvoj atd, ovsem vzhledem k tomu ze napr Google Earth pochazi z projektu KeyHole ktery financovala CIA pres nastrcenou "venture capital" firmu In-Q-Tel.....je mozny uplne cokoliv.....
stojím si za tím, že mít crypto jako open source je nutné, ale už nikoliv nezbytnost.
I uzavřený komerční SW může být zdrojové kódy k dispozici pod různými licencemi a smlouvami a nemusí použít přímo nějakou open source licenci. Pořád platí, že i tak musím věřit autorům a auditorům.
Nejen zdrojové kódy tvoří bezpečnost, ale i forma implementace a nastavení, sám nepřímo píšeš, že konfigurací toho dokážeš hodně zkazit, tohle zatím linuxové distribuce moc neřeší a výchozí konfigurace bývá problém, stejně tak nástrojů, které by ověřili, že celý ekosystém je v pořádku je opět pomálu nebo nejsou vůbec.
Osobně se domnívám, že bychom se měli vrátit zpátky na stromy, výrazně SW zjednodušit a lépe oddělit jednotlivé vrstvy. Bezpečnost celého systému může poslat do pekel jediný špatně nakonfigurovaný nebo aktualizovaný balíček. Proč drtivá většina auditu řeší pouze jednotlivý SW, ale audit na celý SW stack v OSS není. Naopak třeba v komerčním světě bývá pravidlem, že se dělá security audit celého blackboxu najednou.
"... nějaký krypto odborník finančně motivovaný..."
Na auditu techhle veci maji vetsinou zajem predevsim firmy ktery to chtej pouzivat..... a casto se na takovej audit skladaj.....a kdyz uz je hotovej tak ty rozumnejsi firmy nemaj nic proti tomu abyse i zverejnil- nakonec dobrej audit je defacto pro jejich vlastni dobro protoze zvysi jejich vlastni duveryhodnost.......
Navic "security" je p.t. buzzword ktery prodava, vzhledem k IT pruserum ktery se na nas vali zleva zprava..........
Osobne si myslim ze tuhle knihovnu od Googlu stejne nikdo pouzivat nebude podobne jako tohleto crypto ktery Google protlacil do kernelu a ted od toho dava ruce pryc:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-RFC-Remove-Speck
>zdrojáky v cajku...
Ne nadarmo skoro současně vyšel tento článek:
https://www.root.cz/clanky/muzeme-verit-prekladacum-projekty-resici-schema-duverive-duvery/
Jo, zkompiloval. První co jsem udělal bylo, že jsem se vykašlal na tu jejich Bazel hrůzu a napsal si Makefile. Ukázalo se to jako mnohem rychlejší cesta než se v tom pitvat a studovat něco, co už stejně nikdy nepoužiju. A takhle to mám se všemi buildovacími systémy, vždy skončím u Makefile jehož princip je jednoduchý a snadno zapamatovatelný. To je zvláštní paradox všech těhle "cool" build systému ať už jde o tohle nebo třeba CMake - jedním z jejich cílů obvykle bývá zjednodušit programátorovi život, bohužel výsledek je (alespoň u mě) přesně opačný, neboť většinou fungujou jenom do prvního problému - pak člověk zjistí jak netransparentní blackbox to je a kolik dokumentace musí přečíst, aby s tím pohnul...
Tahle knihovna ale řeší jiný problém. To, že máte knihovnu, která uvnitř správně implementuje kryptografii, ještě neznamená, že ji někdo nepoužije špatně. Tink se snaží předejít právě tomu špatnému použití – neřeší tedy kryptografii znova, ale pro stávající knihovny vytváří takové rozhraní, se kterým bude těžké použít je špatně. Je tam uvedený příklad – pokud bezpečnost nějakého řešení závisí na tom, že se nonce nebude opakovat, ta knihovna vůbec nonce nepřijímá jako parametr (kam by programátor mohl nastavovat stále tu samou hodnotu), a místo toho generuje nonce sama.
