Názory k článku SHA-1 není bezpečná, Google ukázal kolizi

Sem si skoro jistej, ze porad najdes v provozu "CNCcka" programovany dratovanim.

Drátováním nevím, ale stále mám (byť velmi omezený) přístup k mašině na děrné pásky.

Pristup je danej smlouvou, pokud mas smlouvu na ktery dodavatel nic negarantuje, tak mas servis tomu presne odpovidajici = zadnej.

Ano, to dnes víme taky, že minulé vedení podepsalo nevýhodnou smlouvu, ale kdo by to byl tušil u zařízení v této cenovce, že.

Mimochodem je zajímavé, že tento přístup (ošetřit si vše smlouvou) nepoužíváš u těch tvých krabiček, které tě kdosi nutí každého půl roku vyměňovat. Proč si to smlouvy nedáš položku, že podpora musí být minimálně 10let? ;-)

Tech masin za miliony mas plnou halu, chces sledovat co se kde podelalo, a ne najmout 30 lidi, ktery to budou obchazet a zkoumat na lokalnich terminalech.

Tyto mašiny mají svou údržbu a revize, takže ty lidi stejně potřebuješ. Ne všechno se dá zvládnout od síťového terminálu.

Cena nevypovida zhola nic o kvalite.

To sice nevypovídá, ale současně člověk neočekává, že se ho snaží ojebat firma, co je na trhu několik desítek let a u zařízení v této kategorii. Kdyby se kupovalo něco na tržnici se slevou za 20Kč a ono to nefungovalo, tak neřeknu ani popel.

Společnost, ve které se budeme chtít všichni vzájemně ojebávat nemůže fungovat.

To ale není pravda, že se s tím zařízením nedá komunikovat. Nedá se s ním komunikovat s aktuálním prohlížečem. Jenže když máte zařízení, které má nezáplatované bezpečnostní díry, tak k němu určitě nechcete přistupovat přímo z běžného webového prohlížeče. Buď použijete nějaký speciální prohlížeč, nebo mezi to zařízení a prohlížeč postavíte nějakou bránu, která bude provoz filtrovat, aby se k tomu nezabezpečenému zařízení nedostal nějaký útok.

Protože špatně bylo už to, že jste se k tomu připojoval běžným prohlížečem před deseti lety. To, že někdo prohlížeč takhle špatně používá, není důvod, proč prohlížeč kazit všem ostatním. A bez toho kažení ostatním to bohužel nejde, protože jakmile budete mít v prohlížeči snadno dostupnou možnost přepnutí na nebezpečné protokoly, útočníci toho zneužijí.

Idealnim resenim by bylo vytvorit prohlizec, ktery by deklaroval, ze je zamereny na komunikaci s takovymito zarizenimi. Podpora vycpelych protokolu, zkazenych certifikatu (tak dlouho po maximalni dobe trvanlivosti preci nemuzou byt pozivatelne), a tak podobne. Nevyhoda soucasnych mainstreamovych prohlizecu je, ze nemuzete mit snadno dve verze na jednom pocitaci, aniz byste se bal o to, ze jeden prepise nejaka data z uzivatelskeho profilu pro ten druhy. Na druhou stranu, tohle by v dnesni dobe mohlu resit kontejnery nebo i plna virtualizace.

Jenže to je špatně, pokud k nezabezpečenému zařízení budete přistupovat univerzálním prohlížečem. Pak může být to zařízení přes prohlížeč snadno napadeno a odstaveno nebo dokonce zničeno. To si musíte rozmyslet – buď je to opravdu zařízení, u kterého si nemůžete dovolit výpadek, a pak se musíte postarat i o jeho bezpečnost a používat speciální bezpečný software. Nebo je pro vás důležitější pohodlí, nějaké výpadky a odstávky nevadí, no a pak by zase neměl být problém ho udržovat aktualizované. Ostatně psal jste, že to zařízení jednou za rok přijede seřídit nějaký technik z Německa – tak proč nechcete být stejně náročný i v softwarové části? Nebo proč nejste stejně benevolentní, jako u toho softwaru, i při řešení toho hardwaru – a když vám pro správu má stačit obyčejný prohlížeč, proč vám pro seřízení nestačí firemní údržbář, který se jinak stará o dveře, světla a topení, s pořádným kladivem?

ma doma televizi, kterou rozhodne pristich 15-20let bude pouzivat

Tak televize má snad vlastní rozhraní ne? I s monitorem :-D

Akorát s těmi 15-20 lety bych to neviděl tak optimisticky, protože ti zruší vysílání ve staré normě a jsi víš kde. Kodeky jsou HW, takže žádný update firmware z h264 neudělá podporu pro h265.

A jestli si někdo pořídí mikrovlnku s https rozhraním, tak je to asi jeho problém. To zařízení nemůže bejt jednodušší (HV trafo, magnetron, časovač), to vydrží věčně, a jestli někdo má potřebu si tam nechat zamontovat i celý komp, tak mu asi není pomoci. (Jinými slovy nechápu, proč by zrovna mikrovlnka měla být připojitelná na počítačovou síť.)

dokonalosti se dosahuje tehdy, když už nejde nic ubrat

+1

Přesně tak, digitálně podepisované či datovou schránkou posílané dokumenty by měly být tak jednoduché, jako ta mikrovlnka. Čili žádné PDF, DOC, JPG, ale plaintext. Kdo by chtěl vytvořit kolizní dokument s jiným textem, ale stejným hashem, by pak musel v textu zvolit a pak permutovat dvacítku znaků, což se v prostém textu nepozorovaně provésti nedá.

> Tedy přidáním MD5 se bezpečnost nezvýší

Podle toho, co víme dnes, to vypadá, že se bezpečnost zvýší, byť ne o tolik, kolik by si někdo mohl představovat. Nejlevnější kolize SHA-1 je dnes za cca $100,000 (nebo ještě mnohen levnější, pokud zkusíte znovupoužít známou kolizi). Za kolik zvládnete kolizi SHA1+MD5? Nejlevnější mi známý způsob odhaduju řádově na $10,000,000, a je nad ním spousta otazníků a limitací. Třeba nejasná míra paralelizovatel­nosti.

Že si nemohu být jist, že není levnější způsob, který by to zvládnul za malou chvíli? To je pravda. Ale jistotu nemám ani u SHA-2/SHA-3.

> zvýší se jenom iluze bezpečnosti, což je vždy nebezpečné – protože se dotyčný nejspíš nechá ukolébat tím, že pro bezpečnost něco udělal, místo aby rovnou řešil přechod na SHA-2.

Souhlas. Pokud to jde, je přechod na SHA-2 lepší z hlediska bezpečnosti a možná i z hlediska výkonu. Vzácně se ale mohou objevit komplikace, které SHA1+MD5 může řešit – třeba absence HW akcelerace u embedded zařízení. Pak je to na zvážení rizik.

Rozdíl je v tom, že SHA-2 a SHA-3 byly navržené s tím, aby odolaly útoku, a bylo to různými způsoby ověřováno. V případě kombinace SHA1+MD5 to tak navržené nebylo a pravděpodobně to nikdo neověřoval. Osobně vnímám velký rozdíl mezi „zkoušeli jsme to rozbít a nešlo to“ a „zatím to nikdo rozbít nezkusil a doufáme, že to bude obtížné“. Proto jsem to přirovnával k home-made šifrám, pro které je typické to druhé tvrzení. A často opravdu mohou reálně „fungovat“, protože se nikomu nevyplatí je rozbíjet. Ale je to sázka do loterie, já dávám přednost těm algoritmům, které se největší experti pokoušeli rozbít a víme, jak dopadli.

Hledání kolize SHA-1 trvá přibližně rok. Hledání kolize MD5 trvá na obdobném hardwaru mnohem méně než sekundu. Myslíte si, že když chcete zlomit obě, stačí ty časy prostě sečíst?

Já myslím, že musíte navrhnout nový algoritmus hledání kolize SHA-1, který z hledání předem vyloučí takové možnosti, které zároveň nejsou MD5 kolizí. Netroufám si odhadovat, o kolik bude takový algoritmus náročnější. Je dost dobře možné, že vůbec, ale může taky platit, že nesmírně.

To, co odkazoval, je skutečně validní útok. A čas je vyšší než součtový. Tehdy šlo najít kolizi MD5 pod minutu, takže proč přičítat celou hodinu k celkovému času?

Ale, jak jsem psal, útok předpokládá, že se ve druhé fázi na jednu z funkcí provede bruteforce. Těžko ve druhé fázi něco optimalizovat, byť vyloučené to samozřejmě není.

Tuto „starou známou věc“ jsem zde i zmiňoval, byť jsem na to navrhoval jít naopak. Ale pozor na podstatné detaily:

Ten příspěvek předpokládá, že SHA-1 lámete hrubou silou. Pak zmíněné skutečně platí – vygenerujete multikolizi MD5 a během „hodiny“ máte 2^80 hodnot se stejným MD5 hashem, které „jen“ musíte projít hrubou silou a najít tam (AFAIK s pravděpodobností 1/2) kolizi SHA-1. No, good luck s 2^80… A vysledná dvojkolize bude mít 160 bloků, tj. 10KiB.

Vy nejspíš predpokládáte, že tu kolizi SHA-1 uděláte pomocí algoritmu, který Google plánuje zveřejnit, a tedy se složitostí od oka pár řádů pod 2^64. No, to teď z fleku nevyvrátím, ale dost o tom pochybuju. Ten algoritmus našel kolizi na dvou po sobě jdoucích blocích, které mohl libovolně volit. Tady ji má najít na 160 blocích, kde ale může volit jen ze dvou variant, a to ještě musí volit po dvou po sobě jdoucích blocích. Jinak řečeno, algoritmus má osmdesátkrát po sobě na výběr ze dvou variant pro následucících 128B. To je dost omezující podmínka, a tuším, že ten algoritmus takto nepůjde použít.

Proto jsem ostatně navrhoval vyrobit multikolize na SHA-1 a teprve MD5 mlátit hrubou silou. Ani tady si nejsem jist, jestli mi to preconditions k útoku dovolí, ale zřejmě je to časově i prostorově úspornější varianta. (Což před deseti lety asi úplně neplatilo, tehdy se moc nevědělo, jak SHA-1 lámat rychleji než hrubou silou.)

Divného je na tom to, že pak nepotřebujete žádné identifikátory, prostě budete všude přenášet jen kompletní data. A i ta data budete přenášet donekonečna, protože spolehlivost přenosu po síti (ale ostatně i z disku nebo z paměti) je chráněná zase jen kontrolními součty.

Netuším, jak byste si to v praxi představoval. Dobře, rsync nebudete používat, protože používá pro zjištění shody dat jen kontrolní součty. Budete tedy přenášet po síti celý soubor. Jenže spolehlivost toho přenosu je na úrovni TCP/IP chráněna zase jen kontrolními součty. Takže když soubor přenesete a budete chtít ověřit, že jste ho přenesl správně, budete ho muset přenést ještě jednou a ty dvě kopie pak porovnat. Jenže nulová není ani pravděpodobnost, že se ten soubor přenese dvakrát se stejnou chybou. To ten jeden soubor budete přenášet donekonečna? Nebo se smíříte s tím, že spolehlivost není 100 % a že prostě existuje nenulová pravděpodobnost, že se to přenese špatně? A když se smíříte s tou nenulovou pravděpodobností, co je špatného zrovna na té pravděpodobnosti, že dojde ke kolizi SHA-1 u dvou reálných souborů?

Mě se líbí, jak vše ženeš ad absurdum.

Je potřeba si uvědomit, že nelze vyřešit všechno. Jenže to současně neznamená, že na místech, kde to řešit lze, se na to řešení vyprdnu. A to je to, co mi na těchto diskusích vadí asi nejvíc. Tedy, když ty soubory mám nebo můžu mít, tak je rovnou porovnám byte po byte. Tam, kde to nejde, tak to prostě nejde a musím spoléhat na nějakou dobrou fci.

Takže tam, kde lze porovnávat celá data, by se měla porovnávat celá data. Ano, všichni víme, že na disku a ram se používají ecc, dokonce se u některých médií rovnou používá samoopravný kód, protože jinak by to nefungovalo vůbec. Ale to přece není důvod pro odstranění další možné kontroly Naopak mě to teda přijde jako důvod pro to dělat další kontroly, takže třeba moderní fs mají vlastní kontrolní součty - i když je má i disk, a některé db mají ještě další kontrolní součty - takže tam ve výsledky mohou být kontroly 3 - disk, fs, db + ještě ecc v ram a cpu.

A když se smíříte s tou nenulovou pravděpodobností, co je špatného zrovna na té pravděpodobnosti, že dojde ke kolizi SHA-1 u dvou reálných souborů?

No především bych chtěl říct, že já se se sha-1 nesmířím v ničem už od roku 2010. Takže řešit toto téma v roce 2017 je pro mě trochu zastaralé, pro mě už zkrátka neexistuje. A o tom bychom se asi měli bavit v první řadě, pro mě zkrátka funkce, u kterých kryptologové naleznou nějaké oslabení, prostě končí. Ano, můžeme se bavit o tom, co teda používat, když i rodina SHA-2 je lehce nalomená, na to odpovídám, že používám sha-512 a velmi intenzivě se dívám po nástupci (jestli to bude sha-3 nebo něco jiného zatím nevím).

Ad absurdum to ženu, protože ty jsi žádnou hranici neuvedl a psal jsi to právě takhle obecně – použití hashe jako identifikátoru je vždy špatně.

když ty soubory mám nebo můžu mít, tak je rovnou porovnám byte po byte
Takže rsync nepoužíváš? Tam soubor máš nebo můžeš mít. Píšeš o kontrolních součtech na úrovni souborového systému – to je ale podle téhle věty také špatně. Tam přece soubor také mám, takže bych neměl pro kontrolu zapisovat jeho kontrolní součet, ale rovnou celý soubor.

Ano, zase jsem to dovedl ad absurdum. Protože ty napíšeš nějaké pravidlo, které by se podle tebe mělo samozřejmě dodržovat – to absurdní je pak ale jenom příklad postupu podle toho pravidla.

já se se sha-1 nesmířím v ničem už od roku 2010
Já jsem z tvrdého použití SHA-1 v Gitu měl špatný pocit už v roce 2005, právě z toho důvodu, že jednou muselo dojít k tomu, že bude SHA-1 pro kryptografii nedostatečné. Ale je to pořád jen ten pocit, že není dobré používat něco, co je označené za zastaralé. Na druhou stranu nevidím pořád problém v tom využívat hash jako identifikátor. Někde se používá i UUID, to má ještě mnohem méně entropie.

pro mě zkrátka funkce, u kterých kryptologové naleznou nějaké oslabení, prostě končí
Pro kryptografické použití jistě. Ale má končit i jako generátor unikátních identifikátorů? Proč?

použití hashe jako identifikátoru je vždy špatně

Je to špatně všude tam, kde je možné používat původní data jak identifikátor. Samozřejmě, teď se můžeme dohadovat o tom, co to přesně znamená "je možné" a kde je ta hranice. To by ale měl vycítit návrhář toho kterého systému.

Takže rsync nepoužíváš? Tam soubor máš nebo můžeš mít.

Ano a rsync má taky mód, kdy se vykašle na nějaké porovnání a rovnou ta data zkopíruje.

Já jsem z tvrdého použití SHA-1 v Gitu měl špatný pocit už v roce 2005

No tak to každopádně. On byl taky Linus docela kritizován a už tehdy reagoval na možné výtky. Na druhou stranu (jak psal O. S. Nekola) je git evidentně dost odolný i proti hodně stupidní fci.

Na druhou stranu nevidím pořád problém v tom využívat hash jako identifikátor. Někde se používá i UUID, to má ještě mnohem méně entropie.

No jenže tím použitím UUID zase může dát vývojář najevo, že tady opravdu nepotřebuje nějakou kryptograficky silnou funkci a že je to opravdu jen identifikátor. Já jsem zastánce silného typování, takže datový typ uuid je mému srdci mnohem bližší, než něco jiného a to, že to má jen 128b (a to ještě pouze v jedné z těch pěti verzí) mi nijak nevadí (v některých případech může být dokonce výhodné použít ty verze s časem).

Návrhář Gitu to evidentně vycítil tak, že tady je SHA-1 jako identifikátor vhodné.

On to uz nekdo zkousel pred lety... misto sha pouzil v gitu nejakou hodne hloupou funkci (tusim ze neco jako 4 bity parity s doplnenim nulami na pozadoavnou sirku) a zkousel, zda se git nerozpadne. Vydrzel.

U svn to asi neudelali ;)

Mně právě není jasné, jak by se do nějakého repozitáře dostal ten podvržený commit se stejným hashem, a zároveň aby se tam nemohl dostat špatný commit s jiným hashem. Podle mne repozitář musí být před špatnými commity chráněn nějak obecně, a nedovedu si představit, že by ta ochrana byla závislá na hashi commitu.

Git identifikuje pomoci sha1 i soubory. Takze si predstavte teoreticky utok (pokud by byl identifikator jen ten sha1): Dejme tomu, ze vim, ze se chysta nekdo poslat do upstreamu pull-request s <goodfile> identifikovanym pomoci nejakeho sha1. Kdyz budu dost rychly, dostanu pred tim do upstreamu nesouvisejici zmenu, ktera ma nejde v /test-data/ i <badfile>, ktery ma stejny sha1. Myslim, ze by se pak mohlo stat, ze pri fetchi toho pull-requestu se <goodfile> nestahne, protoze preci uz soubor <sha1> uz git ma. Misto nej se pak dosadi <badfile>. A skoro vsichni (krome autora pull-requestu) budou mit bad-file.

Kdyz budu dost rychly, dostanu pred tim do upstreamu nesouvisejici zmenu, ktera ma nejde v /test-data/ i <badfile>, ktery ma stejny sha1.
Přičemž to je ale úplně stejný problém, jako když do upstreamu dostanu nesouvisející změnu, která má někde v /test/data i <badfile>, a na hashi přitom vůbec nezáleží. Já pořád vidím problém už v tom, že někdo s úmyslem škodit dostane něco do oficiálního repozitáře. Nebo jinak – na tom, že je v oficiálním repozitáři soubor nebo commit od člověka, který chce škodit, mne vůbec neuklidňuje, že ten soubor nebo commit má unikátní hash.

Jenže v /test/ může být ten soubor jako ukázka dat, proti kterému mají běžet automatické testy, dokonce to může být ukázka toho, že se parser vyrovná s určitým typem chyby. Zatímco <goodfile> v /src/ může být zdroják se stejným sha1, a jako zdroják bude mít ten soubor úplně jiný význam, než v adresáři /test_data/.

Pořád to znamená, že někdo musel záměrně vyrobit kolizní soubory a záměrně je commitnout do repository. Pokud někdo, kdo má úmysl škodit, dokáže protlačit své soubory až do oficiálního repository, je to obrovský průšvih. To, že ty soubory mají stejný hash, je spíš taková perlička.

Pouze jsem uváděl hypotetický útok, pokud by byly splněny dva předpoklady, které myslím splněné nejsou:
1. git identifikuje soubory pouze sha1 - to tu již jiní vyvrátili
2. lze vyrobit soubor s kolizní sha1 k souboru, na který chceme zaútočit, bez toho abychom originál modifikovali.
Bodem 1 jsem si v době psaní nebyl jist. Bod 2 padne někdy v budoucnu. Chtěl jsem jen ukázat, že vhodně zvoleným útokem může být podstrčení pouze jediného souboru, a to ještě maskovaného za testovací data. Soubor s testovacími daty je možné protlačit vhodným technicko-sociálním inženýrstvím. Představuji si to tak, že najdu chybu v originálním software, připravím <badfile> tak aby udělal to co chci a zárovreň aby demonstroval chybu. Submitnu ho jako testcase té chyby, pokud možno i s patchem, takže upstream by měl práci navíc s oddělováním testcase od opravy chyby.

V případě celých commitů je situace složitější. Ale nejsem přesvědčen o tom, že je nereálná.

Ale to pořád uvádíte případ, kdy se bez kontroly dostane do oficiálního repository něco podstrčeného útočníkem. A to já vidím jako velký problém i kdyby tam nedošlo k žádné kolizi hashů.

Ano, a já uvádím, že se to tam může dostat snadno, protože těžko bude někdo kontrolovat zda soubor označený test-input-456.cfg, není náhodou kromě příkladu, testujícího, že bug 456 a 478 při čtení konfigurace opraveny, náhodou i platný soubor default.cfg, ve kterém je chyba typu:
#define SECLEVELS 10
security=SECLEVEL
(tedy záměrné typo nastavující security na prázný řetězec), který jen čeká na záměnu s původním /etc/foo/defau­lt.cfg.

Může se to tam dostat snadno, pokud může útočník snadno dostat své soubory do oficiálního repository. Což je podle mne ten hlavní problém. Pokud je dotyčný přispěvatelem projektu, může napáchat spoustu škod aniž by si hrál s nějakými kolizemi hashů. A pokud je to náhodný přispěvatel, opět měl by ten jeho příspěvek někdo vzít, projít ho, pochopit a případně upravit a pak se pod něj podepsat. Pokud někdo převezme testovací data, aniž by se podíval, jestli skutečně testují to, co má být opraveno, je to, jako kdyby tam ten test vůbec neměl.

Něco podobného je soutěž v tom jak udělat kód, ve kterém je záměrná chyba, tak aby prošel skrz code review:
http://www.underhanded-c.org/, je to docela zajímavé počtení, především pro céčkaře.

Při šifrování a dešifrování platí, že dešifrování musí být inverzní operace k šifrování. Od šifrování také obvykle chceme, aby výstup byl (až na případné zarovnání) stejně dlouhý, jako vstup, aby tedy jakákoli náhodná data byla potenciálním výstupem šifrování. Z toho plyne, že i šifrování musí být inverzní operací k dešifrování. U asymetrických šifer tedy platí, že když na vstupu provedete transformaci s pomocí privátního i veřejného klíče, přičemž nezáleží na pořadí (protože obě transformace jsou navzájem inverzní), dostanete opět vstup.

Vy za šifrování označujete vždy transformaci veřejným klíčem a za dešifrování vždy transformaci soukromým klíčem (proto vám pak podepisování vychází jako dešifrování). Obvyklejší je myslím označovat to podle pořadí operací, tj. první operaci označovat za šifrování a druhou za dešifrování. Už pro to, že tohle označení bude fungovat i pro případy, kdy šifrování nepokryje celý možný obor hodnot – kdybyste v takovém případě začínal dešifrováním, může se vám stát, že narazíte na vstup, kro který není dešifrování definováno. Třeba kdybyste šifrování definoval jako zdvojení každého písmena a dešifrování jako sloučení dvou stejných písmen na liché a následující sudé pozici (takže„A“ by se zašifrovalo jako „AA“), není pro vstup „AB“ dešifrování definováno.

Chápu vaši nechuť označovat za výsledek šifrování něco, co je veřejné, nicméně u podpisu jsou veřejné oba texty – jak vstupní text, tak výsledek transformace.

Bezpečnost je daná tím, že soukromý klíč nikdy nesmí být zveřejněn, teprve z toho je odvozené, kterou transformaci kdo může použít a z toho plyne pořadí těch transformací.

Šifrování a ověření podpisu hashe jsou matematicky vždy totožné operace, stejně jako dešifrování a vytvoření podpisu z hashe. To vyplňování při šifrování není striktně vzato součástí šifrování, je to příprava vstupu pro šifrování. A hashování vstupního dokumentu není součástí podepisování, podepisuje se vždy hash dokumentu, a podepisující někdy ani vstupní dokument nezná, zná jenom hash – např. při vystavování časových razítek (což, pravda, není jen podpis hashe, ale podpis hashe plus časové značky).

Šífrování je u mě operace, která útočníkovi prakticky nedovolí dostat se k původnímu obsahu. To bývá i účel šifrování. Naopak dešifrování je operace, kterou může provést pouze vyvolený, což rozhodně není vlastník veřejného klíče.

Přeneseně tak můzeme nazývat operace, které sice slouží k něčemu jinému (zde podpisy a jejich ověřování), ale matematicky tomu odpovídají.

> Vy za šifrování označujete vždy transformaci veřejným klíčem a za dešifrování vždy transformaci soukromým klíčem (proto vám pak podepisování vychází jako dešifrování).

Ve výsledku ano, z důvodu, který jsem uvedl výše.

> Obvyklejší je myslím označovat to podle pořadí operací, tj. první operaci označovat za šifrování a druhou za dešifrování.

Jenže pak to neodpovídá ani sémanticky (to ani u mě – podpis nemá sémanticky nic společného se (de)šifrováním) ani matematicky. Je to prostě operace prováděná jako první a operace prováděná jako druhá. Podobnou zkratku, jakou jsem tu kritizoval na Rootu, bych pochopil třeba na iDnes, kde je jiná skupina čtenářů i redaktorů.

> tohle označení bude fungovat i pro případy, kdy šifrování nepokryje celý možný obor hodnot

To vím. Však jsem úmyslně zmiňoval RSA, kde se to takto používá, a nepsal to obecně.

> Bezpečnost je daná tím, že soukromý klíč nikdy nesmí být zveřejněn, teprve z toho je odvozené, kterou transformaci kdo může použít a z toho plyne pořadí těch transformací.

Ano. Ale nemohu si vždy libovolně vybrat, který klíč bude soukromý a který veřejný. Odvodit veřejný klíč ze soukromého jít může, naopak ne. Provádět oba směry transformace soukromým klíčem jít může, veřejným ne.

> To vyplňování při šifrování není striktně vzato součástí šifrování, je to příprava vstupu pro šifrování. A hashování vstupního dokumentu není součástí podepisování, podepisuje se vždy hash dokumentu, a podepisující někdy ani vstupní dokument nezná, zná jenom hash

Jak se to vezme – záleží, jak moc highlevel/lowlevel pohled chceme. Pokud například chceme mít podepisovací schéma, které není náchylné na malleability, s čistým RSA si nevystačíme. Stejně tak u šifrování. Zmínkou o paddingu jsem chtěl vyhovět i těm, kteří mají více high-level pohled a mohli by namítnout, že to přece není úplně totožná operace – padding/hash tam potřebujeme nejen kvůli délce zprávy, ale i kvůli bezpečnosti, nelze to tedy vynechat. Ostatně tu námitku vznáší i autor článku, který jsem odkázal.

Ale jinak asi je fakt, že RSA by mělo odkazovat na čisté (samostatně nepoužitelné) primitivum RSA, zatímco pro šifrování budeme mluvit o RSA-OAEP, pro podepisování budeme mluvit o RSA-SHA256 apod. Problém je, že se často uvádí pouze RSA (popř. AES), i když jde o jeden z mnoha dílků skládačky.

Pokud šifrování používáte pro operaci, která znemožní útočníkovi dostat se k původnímu obsahu, pak nemůžete pojem „šifrování“ vůbec používat v kontextu elektronického podpisu – protože tam jsou z principu oba dva bloky dat veřejné, jak hash dokumentu tak jeho transformovaná podoba.

Vaše pojmenování transformace soukromým klíčem jako „šifrování“ sice má svou logiku, ale neodpovídá to tomu, jak se ta slova běžně používají. Běžný význam slov je ten, který jsem popsal – první transformace je vždy šifrování, druhá dešifrování. Když se někde píše o elektronickém podpisu a používá se pojem „šifrování“, většinou se píše o tom, že hash dokumentu jeho autor zašifruje privátním klíčem, při ověření podpisu se pak podpis dešifruje klíčem veřejným. I když je pravda, že třeba česká Wikipedie u popisu algoritmu RSA pro podpis píše jakoby „dešifrování“, takže tam je použitá vaše terminologie, ale aspoň je to zdůrazněné tím „jakoby“ a uvozovkami. Ale je to jediný případ, který jsem našel, jinak se v publicistických textech používá pro podpis „šifrování soukromým klíčem“, v odborných textech se to spíš popisuje přímo matematickými operacemi.

Jaké termíny použijete samozřejmě záleží na vás, ale když je bez upozornění použijete opačně, než jak je většinou zvykem, je to matoucí.

> protože tam jsou z principu oba dva bloky dat veřejné, jak hash dokumentu tak jeho transformovaná podoba

Znamená to, že když zašifruju veřejně známý text, a útočník se nějak dozví, že to je zrovna ten text, tak už nejde o šifrování? Ne. Pouze útočník má apriorní znalost a z ciphertextu se nedozvěděl o plaintextu nic, co by nevěděl už předtím. Ano, mohl jsem to tak rozepsat už předtím, ale příspěvek by byl s tímto přístupem dvakrát tak dlouhý: Útočník se z ciphertextu dozví maximálně délku plaintextu a všechno, co lze vyvodit z délky plaintextu v kombinaci s jeho apriorními znalostmi.* Byl by tak ale můj komentář srozumitelnější?

> neodpovídá to tomu, jak se ta slova běžně používají

Co mám považovat za běžné používání? Pokud spíše laickou veřejnost, kde na iDnesu označují SHA-1 za „šifru“ (byť v uvozovkách), tak tam to ještě chápu. Ale něco na základě takového textu pochopit mi pak přijde dost obtížné. Pokud ale jsme na odborném serveru, dá se čekat, že čtenáři takového článku budou vědět, že kryptografie není jen o šifrování. A tedy se budou věci nazývat pravými jmény, tedy místo „Zašifrujete otisk a získáte elektronický podpis konkrétního dokumentu.“ spíše něco jako „Do podepisování typicky vstupuje z praktických důvodů pouze otisk, takže dva dokumenty se stejným otiskem budou mít stejný podpis.“.

Zmínka o tom, že v RSA jde de facto o dešifrování, měla jen ilustrovat, jak je zmínka o šifrování nepřesná.

Co so vzpomínám na předmět Applied cryptography na MU FI, na první přednášce k terminologii bylo „Nešifrujeme soukromým klíčem“. Tehdy jsem si říkal, proč to vlastně zmiňuje.

*) Praktická ukázka: pokud útočník předem ví, že zpráva je buď „ano“, nebo „ne“, může z délky zprávy odvodit i celou původní zprávu.

V případě podepisování to ale není „útočník se nějak dozví“. Podepisování je založené na tom, že ověřovatel podpisu zná hash dokumentu. Takže tam se ta transformace neprovádí pro to, aby se něco skrylo před útočníkem. Ostatně při použití symetrické šifry zastává šifrování obě funkce – jak zabránit útočníkovi dozvědět se text zprávy, tak to zároveň pro příjemce ověřuje autenticitu zprávy, protože nikdo jiný než vlastník klíče nemohl zprávu správně zašifrovat.

V souvislosti s elektronickým podpisem se spojení „zašifrovat hash privátním klíčem“ běžně používá. Je to tedy rozhodně správnější vyjádření, než „rozšifrovat hash privátním klíčem“.

> Takže tam se ta transformace neprovádí pro to, aby se něco skrylo před útočníkem.

Ano, a navíc tento druh transformace to ani není schopen zajistit, proto tomu neříkám šifrování

> Ostatně při použití symetrické šifry zastává šifrování obě funkce – jak zabránit útočníkovi dozvědět se text zprávy, tak to zároveň pro příjemce ověřuje autenticitu zprávy, protože nikdo jiný než vlastník klíče nemohl zprávu správně zašifrovat.

To je (relativně rozšířený) omyl. Ano, útočník bez klíče nemohl zprávu zašifrovat, ale mohl zprávu pozměnit (vizte malleability). Proto se se symetrickými šiframi ještě používá MAC. Pripadně existují AEAD módy, ale to je v podstatě jen skrytý MAC.

> V souvislosti s elektronickým podpisem se spojení „zašifrovat hash privátním klíčem“ běžně používá.

Setkal jsem se s tím poprvé asi včera. A nemám pocit, že bych se kryptografií nezabýval.

> Je to tedy rozhodně správnější vyjádření, než „rozšifrovat hash privátním klíčem“.

Neodpovídá to ani sémantice ani matematické operaci. Nesedí to typově. Narozdíl od rozšifrování hashe.

Pokud nejde o matematické detaily, mluvme o podepisování a ověřování podpisu, ne o šifrování/deši­frování.

A pokud nám jde o tyto detaily, tak podepisování pomocí RSA v podstatě odpovídá dešifrování.

Ta transformace se ale neprovádí ani proto, abych odkryl něco, co bylo skryté, takže pak je špatně i nazývat to dešifrování.

Záleží, co chci říct:

Pokud chci ukázat důvod, proč to provádím, pak je špatně psát o šifrování/deši­frování. Proto dávám přednost se slovům šifrovat/dešifrovat úplně vyhnout v takovém případě.

Pokud chci popsat, čemu to odpovídá matematicky, nevidím v tom problém.

P.S.: původně ta zmínka o dešifrování měla být jen tak na okraj. Hlavní sdělení mělo být, že nejde o šifrování. Možná jsem to měl jinak formulovat…

Já jsem se také doposud setkal s pojmem "šifrování" ve smyslu udělat ze známeho textu text nový, odvozený matematickou operací. Tedy první operace, ať už je dělaná soukromým, nebo veřejným klíčem. Dešifrování je pak získání původního textu, tedy operace druhá v pořadí.
Zmatení vzniká až díky tomu, že k "zašifrování" hashe pro podpis se používá stejná operace jako při "dešifrování" zprávy při normálním šifrování.