Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Ondřej Novák 16. 10. 2015, 16:19:12
-
Chtěl bych nějak vizualizovat kryptograficky otisk (hash) zprávy. Nějak pěkně graficky, aby uživatel snadno na první pohled dokázal porovnat dva otisky a snadno se přesvědčit, že jsou stejné. Neměl by někdo nějaký nápad? Třeba nějaké náhodné malování na canvas?
Příklad, když uživatel uvidí na obrazovce obrázek divného stromečku a na mobilu stejný obrázek divného stromečku (tedy vygenerovaný obrázek), pochopí, že na mobilu má stejný otisk jako na obrazovce počítače.
Ideálně by bylo, aby se jednalo o kresbu, nejlépe monochromatickou. S barvama je potíž, lidi bejvají barvoslepí.
Nějaké fraktály? Ale zase aby se to počítalo rychle, ideálně v JS
-
Tak nevim, jak by clovek na prvni pohled poznal rozdil mezi dvema divnymi stromecky, vygenerovanym podle hashu, ktere se lisi treba jen v par bitech. Ale co treba kdybyste vypocital tri kontrolni soucty hashu podle ruznych algoritmu a vysledek prevedl do prislusneho intervalu cisel (treba udelal modulo a pouzil zbytek) a zobrazil jako hodinky: vteriny, minuty, hodiny. Porovnanim pozic tri rucicek zjistite, jestli existuje rozdil. Ovsem pokud rozdil v pozici neexistuje, nemusi to nutne znamenat, ze jsou hashe stejne a ted je otazka, jaka je pravdepodobnost toho, ze takova situace nastane.
Alternativa: misto hodinek nadefinujte vetsi sadu obrazku a podle tech kontrolni souctu z ni vypichnete tri obrazky a zobrazte je ve stylu jednorukeho bandity. Takze kdyz uzivatel uvidi na obou displayich treba jablko, srdce a prase, muze doufat, ze hashe sedi. Zde by to slo rozsirit na vice obrazku, podle toho, kolik jste schopen vygooglovat algoritmu na vypocet kontrolniho souctu.
-
První, co mne napadlo: Co bajt, to osm bodů vysoký sloupeček, 16 bajtů - obrázek 8×16 bodů, zvětšený 2-4×.
Druhý nápad: Každý bajt by byl azimutem pro úsečku, další bajt by na ni navazoval. Případně by to mohly být půlbajty (vždy 16 cest). Vznikl by zajímavý had.
Stromeček: Kmen by měl určitou délku a vystupoval pod určitým úhlem odvozeným z půlbajtu, Z něj by vystupovalo několik větví...
Stromečky by vyrůstaly ze všech 4 stran nebo z rohů.
-
Stromeček byl jen příklad. Já samozřejmě dál prohledávám googla a našel jsem popis toho, co je v ssh, tedy algoritmus "ožralého kněze" který generuje ty známé obrázky v SSH
+--[ RSA 2048]----+
| o . |
| . .o.o .|
| . o .+.. |
| . ...=o+|
| S . .+B+|
| oo+o.|
| o o. |
| . |
| E |
+-----------------+
Blbý je, že je to definované pro asciiart a já mám k dispozici víc, minimálně canvas v javascriptu. Ale dalo by se to použít. Nebo z toho vyjít. Beru to jako poslední možnost. (další věcí je, že já používam SHA256, která má 32 bajtů - ale mohl bych ji zahashovat ještě třeba MD5 :)
Napadly mě nějaké fraktály, ale zrovna nemohu najít žádný rozumný. Taky je problém právě s tím, že by každý hash měl generovat opravdu jiný obrázek, na první pohled rozpoznatelný, že je jiný. A pokud to někde bude generovat podobné obrázky, aby nešly jednoduše forgnout, tedy aby útočník neměl možnost snadno vygenerovat takový otisk (třeba hrubou silou), který bude podobný tomu co uživatel vidí. Takže trošku i bezpečnostní problém
-
QR kód hashe z hashe? Pokud ten telefon dokáže zobrazit "obrázek", tak má s největší pravděpodobností i foťák.
-
QR kód hashe z hashe? Pokud ten telefon dokáže zobrazit "obrázek", tak má s největší pravděpodobností i foťák.
No právě že já nemám problém přenést ten hash do telefonu právě pomocí QR kodu. Ja to potřebuju proto, aby uživatel měl jistotu, že oskenoval správný kód, že tedy podepisuje (ano, jde o DSA, přesněji o ECDSA, napřiklad bitcoinovou transakci, nebo nějaký kritický příkaz na webové aplikaci, třeba smaž všechny fotky v galerii) to co vidí na obrazovce
-
Napadly mě nějaké fraktály, ale zrovna nemohu najít žádný rozumný. Taky je problém právě s tím, že by každý hash měl generovat opravdu jiný obrázek, na první pohled rozpoznatelný, že je jiný. A pokud to někde bude generovat podobné obrázky, aby nešly jednoduše forgnout, tedy aby útočník neměl možnost snadno vygenerovat takový otisk (třeba hrubou silou), který bude podobný tomu co uživatel vidí. Takže trošku i bezpečnostní problém
S temi fraktaly je to docela problem. Sice muzes napriklad z prvnich x bitu ziskat napriklad vzorecek (typ fraktalu), dalsim obarvovaci metodu atd. atd., jenze spousta parametru asi povede bud ke konstantni barve nebo k nejakemu nahodnemu vzorku. Skutecne by asi byla lepsi ta metoda, co nabizi predrecnici - mit rekneme 256 jednoduse rozpoznatelnych obrazku (kytka, prase, flaska piva, dopravni znacky, panacek...) a pro kazdych 8 bitu hashe to nasazet vedle sebe popr. jeste par bitu na barvu (ale fakt par, urcite ne 24 bitove barvy, spis 8 peknych barev, ne RGB).
-
Tohle by tě mohlo zajímat: Hash Visualization: a New Technique to improve Real-World Security (http://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf)
-
Taky: http://www.random-art.org/about/ (z http://stackoverflow.com/questions/3587569/easy-to-remember-fingerprints-for-data)
-
Napadly mě nějaké fraktály, ale zrovna nemohu najít žádný rozumný. Taky je problém právě s tím, že by každý hash měl generovat opravdu jiný obrázek, na první pohled rozpoznatelný, že je jiný. A pokud to někde bude generovat podobné obrázky, aby nešly jednoduše forgnout, tedy aby útočník neměl možnost snadno vygenerovat takový otisk (třeba hrubou silou), který bude podobný tomu co uživatel vidí. Takže trošku i bezpečnostní problém
S temi fraktaly je to docela problem. Sice muzes napriklad z prvnich x bitu ziskat napriklad vzorecek (typ fraktalu), dalsim obarvovaci metodu atd. atd., jenze spousta parametru asi povede bud ke konstantni barve nebo k nejakemu nahodnemu vzorku. Skutecne by asi byla lepsi ta metoda, co nabizi predrecnici - mit rekneme 256 jednoduse rozpoznatelnych obrazku (kytka, prase, flaska piva, dopravni znacky, panacek...) a pro kazdych 8 bitu hashe to nasazet vedle sebe popr. jeste par bitu na barvu (ale fakt par, urcite ne 24 bitove barvy, spis 8 peknych barev, ne RGB).
Ale kdybys na fraktalech trval, tak asi nejjednodussi bude pouzit: http://www.root.cz/clanky/markus-ljapunovovy-fraktaly/
Zajimat Te budou kapitoly 5 a vys.
-
Co takhle vzít hash v hex, stripnout po dvou znacích. Z prvního udělat azimut (360/16), z druhého délku. Vykreslovat od středu canvasu.
S tím by nemuselo být marné si pohrát. Už vím, co budu dělat dnes večer :)
-
Vypište ten hash hexadecimálně třeba po čtyřech číslicích třeba čtyři skupiny na řádku. Nebo nějak podobně, prostě hexadecimální výpis zformátovaný pro snadné čtení.
Porovnáním nějakých obrázků ten hash efektivně zmenšíte na pár bitů, protože kdyby byl delší, začnou si ty obrázky být podobné a útočník může relativně snadno vygenerovat vstup, který bude dávat jiný hash ale podobný obrázek. Třeba pokud byste dal dohromady 256 různých obrázků (fotek), budete mít s výběrem dost práce, a přitom byste takhle dokázal odlišit jen osmibitové hashe.
-
To je pěkný nápad, ještě mě napadlo to stripnout po trojicích, ze třetího udělat odstín čáry a mezi sousedními čarami udělat černobílé gradienty. To by mohlo dokonce i hezky vypadat.
-
Reakce byla míněna na M. Tanečka.
-
Lepší by bylo vzít hodnotu odstínu z dvojice znaků - 255 odstínů šedi :-) (po trojicích to byl docela hloupý nápad).
-
Rekl bych, ze cokoliv, co obrazky bude generovat podle jakehosi algoritmu, ztroskota na komplexnosti vysledku (viz tez Bystroushaak: Hash Visualization: a New Technique to improve Real-World Security). User bude drzet telefon vedle monitoru, cumet na to, jak puk a rikat: "Je to stejne, neni to stejne, that is the question". Krome toho by asi bylo dost tzke otestovat vysledek pro vsechny hashe a mohlo by se stat, ze pro spoustu hashu vyjde jakysi kompletne nevyrazny obrazek, ktery se bude podobat milionu jinych kompletne nevyrazny obrazku. Nebo naopak cmaranice, jak kdyz nekdo rozepisuje propisku, ktera se bude podobat milionu jinych cmaranic, jak kdyz nekdo rozepisuje propisku.
-
To je právě docela otázka. Pokud by se použil ten nápad s úhlem a délkou úsečky, tak by to mohlo podstatně změnit obrázek i v situaci, kdy se budou hashe lišit v jediném znaku (odstíny šedi by to mohly zvýraznit a přidat další odlišnost pro případ, že by byly využity na jednom místě dvě úsečky podobných délek). Sice by se dala najít kombinace znaků, kdy by si se úhly navzájem vyrušily a úsečky by díky tomu šly podobnými směry, ale musel by zde být nějaký rozdíl v ostrosti úhlů a ten bude při minimální odchylce 22,5° jednoznačně patrný. To je jeden z důvodů, proč se mi ten nápad líbí. Chtělo by to nějakého matematika, ale myslím si, že by teoreticky mohla vzniknout množina unikátních obrázků.
-
Jediný problém s podobností se bude týkat posledních znaků hashe. Ale to už se dá nějakým způsobem pohlídat (i kdyby se za obrázek měly ty dvě písmena pro kontrolu napsat, nemluvě o grafickém zapracování do obrázku).
-
Případně by se dal zvýšit pomyslný činitel rozlišitelnosti přidáním váhy průhlednosti jednotlivých gradientů podle pořadí čar, mezi kterými by byly vykreslovány.
-
To mi vsechno pripada, jak reseni pro jine lidi, nez BFU. Osobne sazim na reseni ve stylu jednorukeho bandity: tri, az sest obrazku nejakym zpusobem vybranych podle hashe. I kdyz bude existovat sance shody dvou hashu, porad asi to bude pouzitelnejsi, nez nejaka algoritmicka vizualizace. Slo by to udela i uplne presne. Ovsem to by znamenalo 16 obrazku vybranych z mnoziny 2^16 a to bych chtel videt tazatele, jak to vsechno patla v Gimpu. A i kdyby to nekde nasel hotove, tak by to mozna zabralo moc mista, aby to cpal do telefonu.
Tady by to chtelo matematika, aby spocutal, jaka je pravdepodobnost omylu pro urcitou velikost mnoziny obrazku.
-
Když použijete jenom 256bitový hash a každá čárka bude reprezentovat jeden bajt (jak je popsáno v tom návrhu), bude to 32 čárek. I když ten hash změníte víc než jen v jednom písmenu, ty obrázky budou pořád podobné. Uživatel by je rozlišil jedině tehdy, pokud bude kontrolovat 32 čárek jednu po druhé.
-
Pro Jirsák: Jenže tím, že jednotlivé čáry navazují jedna na druhou, vznikají různé a v mnoha případech hodně odlišné tvary. Uživatel tedy v drtivé většině případů pouze zkontroluje, jestli se tvar podobný něčemu, jako je vánoční stromek podobá tvaru srovnatelnému s třiceticípou hvězdou na druhém obrázku. Je potřeba si uvědomit, že jediná změna úhlu kompletně vychýlí celý zbytek obrázku úplně jiným směrem. Tedy i kdyby byl jinak identický, je pro BFU naprosto odlišný od podobného hashe.
Pro JardaP: V tom máte určitě pravdu. Na to, abychom to nějak jednoznačně rozlouskli, by bylo určitě matematika potřeba. Osobně si myslím, že by ve výše popisovaném případě vznikl jednoduchým způsobem využitelný obrázek, který by přes svou abstraktnost byl použitelný. Na druhou stranu je také pravda, že Vaše řešení má také něco do sebe, nicméně jak říkáte, bylo by docela zdlouhavé nakreslit větší množství takových obrázků. Sice by trošku mohlo pomoci zobrazovat stejné obrázky v jiné barvě, nicméně při požadavku na možnost využití barvoslepými by to asi byl skutečně problém.
-
@jardaP
Obrázky už máme, říká se jim latinka :)
@Filip Jirsák
Je to zatím na vodě, to je jasné, chce to na tom zapracovat. Ale ten azimut je prostě super :)
-
jednotlivé čáry navazují jedna na druhou, vznikají různé a v mnoha případech hodně odlišné tvary
Jo takhle, ty čáry na sebe mají navazovat. Takže to prostě bude změť čar přes sebe. Čemuž by se dalo zabránit tím, že se nebude dělit 360 stupňů, ale jen 180, takže rozdíl by byl jen o něco víc než 10 stupňů. Nebo by zůstal 22,5 stupňů, ale čárek by bylo 64 (pro 256bitový hash).
To ale není podstatné. Podstatné je to, že sice v mnoha případech mohou existovat hodně odlišné tvary, ale zároveň v mnoha případech ty tvary budou podobné. A vzhledem k tomu, že to budou převážně hodně divné tvary, stačí útočníkovi ten tvar napodobit jen trochu.
Je to zatím na vodě, to je jasné, chce to na tom zapracovat. Ale ten azimut je prostě super :)
Na tom, že na první pohled odlišnými obrázky dokážete prezentovat jenom pár bitů informace, nezmění jakákoli práce vůbec nic. A víc bitů informace zase naopak znamená vznik obrázků, které jsou podobné. Pro člověka bude mnohem těžší najít změnu v něčem tak nejednoznačném, jako jsou nejasné tvary v obrázku, než najít změnu v nějakém znaku, na které je člověk zvyklý.
-
Mezi námi, zkonstruovat hash tak, aby se lišil v jednom bajtu nebo dokonce bitu je docela obtížné, nebo nemožné. Princip hashe by měl být, že malá změna způsobí že vyjde naprosto jiný hash, který se nepodobá ničemu.
Když to vezmu do důsledků pokud předložím uživateli dva hashe, které se liší v jednom písmenku, většina si toho nevšimne. Nikdo nebude kontrolovat, že jsou všechna písmenka stejná. Když kontroluju správnost bitcoinové adresy, koukám jen na první čtyři a poslední čtyři znaky. Taky hlavně proto, že spoléhám na interní checksum, který by překlep v jednom znaku měl odhalit (on by měl odhalit i překlep ve více znacích, když má vyhrazeny celé 4 bajty)
Když budu dělat podepisování tajným klíčem v dedikovaném zařízení, třeba v mobilu, nebo v Trezoru, mohu na display zařízení zobrazit celou zprávu, kterou podepisuju. To funguje do té doby, dokud jde o krátkou zprávu. Jak podepíšu dokument ve Wordu?
Smyslem ochrany má být, že uživatel nahraje dokument, zobrazí se mu hash a adekvátní obrázek. Měl by si samozřejmě spočítat hash bokem a ten obrázek taky vygenerovat. Věří webové stránce, že to udělá správně. Pokud ale technika podpisu probíhá přes třetí stranu, chce mít uživatel pocit, že to so v zařízení odsouhlasí je skutečně ten dokument, který na stránku uploadoval. Bez zobrazení samotného dokumentu mu zbývá zobrazit otisk, tedy celý hash a porovnat jej s tím co mu vyšlo při vkládání dokumentu. Tak má jistotu, že nedošlo k pozměnění požadavku cestou. Má to pokrýt nejjednoduší způsoby hacknutí. Těžko někdo bude k právě vloženému dokumentu provádět hledání hodně podobného hashe, když je to mnohdy operace na několik let či staletí.
Mimochodem, když člověk nahrává dokument do nějakého systému veřejné nebo poloveřejné zprávy (třeba pojišťovna) mnohdy tam sedí Active X, podepisuje privátním klíčem certifikátu a zobrazuje SHA-1 Hash místo obsahu dokumentu a čeká, aby to uživatel odbouchnul. Tomu nic nezbude a doufá, že podepsal opravdu ten dokument, který chtěl podepsat,
-
@jardaP
Obrázky už máme, říká se jim latinka :)
Ano, to sice mame, ale kdyz budu chtit reseni ve stylu, ze kazde dva bajty hashe prevedu prave na jeden znak a budu tak mit skupinu sestnaci znaku, coz porovnam snaze, nez 64 znaku hexa vypisu tech 32 bajty sha256, budu muset sahnout po cinske abecede, abych ziskal 65526 znaku, a tu zase neporovnam, protoze ji neumim cist.
I kdybych zvolil to, co jsem puvodne narhl a napriklad spocital tri az ctyri ruzne kontrolni soucty podle ruznych algoritmu a podle vysledku vybral nejaky znak z mnoziny, tak pri pouziti pouhych 26 znaku latinky, by rozptyl byl prilis velky. Tady by prave byl potreba matematik se znalosti statistiky, ktery by dokazal spocitat/odhadnout pravdepodobnost chyby pri pouziti mnoziny o X znacich a tech nekolika ruznych typu kontrolnich souctu. Tipoval bych ale, ze 26 je malo.
Kurva, jak by se vlastne pocitala takovat pravdepodobnost kolize?
-
Mezi námi, zkonstruovat hash tak, aby se lišil v jednom bajtu nebo dokonce bitu je docela obtížné, nebo nemožné.
U hashovacích funkcí, které dnes považujeme za bezpečné, to můžeme považovat za nemožné. Jenže úplně něco jiného je zkonstruovat hash, který povede na obrázek, který bude na první pohled podobný. To je podle mého názoru velmi snadné, protože stačí vytvořit (podle mého názoru) pár desítek nebo stovek libovolných hashů a jeden z nich povede na podobný obrázek. No a ty náhodné hashe jednoduše vytvoříte tak, že vytvoříte tolik vstupů, které vyhovují vašim potřebám (tj. jsou tam potřebné údaje a ostatní údaje se mění) a klasicky je zahashujete.
Těžko někdo bude k právě vloženému dokumentu provádět hledání hodně podobného hashe, když je to mnohdy operace na několik let či staletí.
No právě. Jenže vy to celé chcete oslabit k nepoužitelnosti tím, že místo aby útočník roky (se započtením rozvoje techniky a prolamování hashovacích funkcí) vytvářel dokument s podobným hashem, bude pár sekund vytvářet dokument s podobným obrázkem.
Stačí si uvědomit jednoduchou věc. Hashe fungují na tom principu, že prostor možných hashů je nepředstavitelně obrovský. Naproti tomu prostor obrázků, které jsou na první pohled nezaměnitelné, je malinký. Ty obrázky můžete nahradit krátkým hashem, který bude mít zhruba stejně velký prostor hodnot, jako ty obrázky. I takové CRC-32, což ani není hash, vám dá řádově víc výstupů, než kolik dokážete vytvořit obrázků, které budou na první pohled různé. Pokud chcete to zabezpečení postavit na obrázcích, představujte si, že to místo toho zabezpečujete CRC-32. Stačí vám to?
-
V obrázkovém řešení vidím jediný smysl - WOW efekt. Jinak mi přijde lepší vypsat prostě ten hash, což jsou přeci právě obrázky poskládané vedle sebe, nic jiného. Záměnou za obrázek se nic neřeší, jen vynálézá kolo (alespoň mi to tak přijde). Pokud trváte na obrázku, stačí použít obrázkový font.
Pokud si pamatuju dobře, tak https://en.wikipedia.org/wiki/SHA-3 umí variabilní délku hashe, takže si můžete vybrat kompromis mezi rizikem kolize a délkou textu, který musí uživatel číst. A řešení je hotové. Nebo se pletu?
-
Abych nebyl špatně pochopen - jde mi o to, že písmo samo o sobě už jsou snadno rozpoznatelné obrázky, navíc je jich dost a jsou na ně lidé adaptovaní. Takže mi přijde přímočará cesta použít.
Ale ještě mě napadlo, že by bylo dobré, pokud by se hash nějak přeložil na slova, která mají význam. Těch slov je v běžném jazyce snad dost a rozhodně snáze poznám rozdíl mezi dvěma souslovíma než mezi dvěma podobnými obrázky. Jedině, že by byly ty obrázky navrstvené přes sebe...
Takže co třeba vypisovat citáty ze Shakespeara? :-)
-
Pokud si pamatuju dobře, tak https://en.wikipedia.org/wiki/SHA-3 umí variabilní délku hashe, takže si můžete vybrat kompromis mezi rizikem kolize a délkou textu, který musí uživatel číst.
Nestačí u libovolné „rozumné“ hashovací funkce prostě část výstupu zahodit?
Takhle se dělají taková ta divná čísla jako SHA-224.
Jinak jak píše Filip Jirsák - myslím, že vygenerovat kolizi nebude náročné.
-
Jakožto dlouhodobý uživatel vizuálních hashů v SSH prostě nemůžu souhlasit se zde uvedenými argumenty.
Jednak to prostě není na wow efekt. Člověk zpracovává vizuální informace podstatně lépe, než symbolické. To že je běžný hash také „vizuální“ je pěkná blbost, protože ho musím prvně přečíst, pak pochopit a tak je z něj sáhodlouhá matlanice symbolických znaků, kde nepoznám nic, pokud si ho vůbec kdy budu schopný zapamatovat. Oproti tomu zapamatovat si obrázek je podstatně jednodušší, což mám potvrzeno praxí, protože to používám.
Dále nevím, co se tu pořád řeší s 255 obrázky a kolizemi. Obrázek má podstatně větší prostor všech možných kombinací, než kdy bude mít string o 32 znacích. OP se může omezit na mixování různých tvarů, kde prostě může třeba i formálně dokázat, že tam nic takového jako kolize nikdy nebude (myšlena kolize, že dva různé hashe vytvoří stejný/podobný obrázek, nikoliv pro vstupní data do toho hashe).
Pokud se to správně implementuje, tak je to jen jiný formát serializace hashe, v čemž nevidím nic špatného.
-
Největší problém je vytvořit vlastnosti, které budou schopny obsáhnout alespoň bajt informace, navíc tak, aby bylo vizuálně jednoduché dané hodnoty rozeznat. Ve výsledku to není nic jiného než čárový kód, ale optimalizovaný pro lidské oko.
Kolize nemá cenu řešit, to je problém algoritmu otisku, ne jeho zobrazení.
-
Oproti tomu zapamatovat si obrázek je podstatně jednodušší, což mám potvrzeno praxí, protože to používám.
To je ovšem jenom chyba v pozorování. Zkusil podstrčil vám někdy někdo podobný obrázek, jestli byste si všiml rozdílu? Nezkusil. Kdybyste si to vyzkoušel, nestačil byste se divit, u jak rozdílného obrázku jste si stále ještě myslel, že je to ten, který si pamatujete. Zvlášť když očekáváte, že by to měl být ten samý obrázek.
Obrázek má podstatně větší prostor všech možných kombinací, než kdy bude mít string o 32 znacích.
V tom problém není. Problém je v tom, že lidský mozek drtivou většinu těch informací zahodí. Můžete si to velice snadno vyzkoušet. Vezměte si nějaký nekomprimovaný obrázek, a ten uložte jako JPEG, klidně s 90% kvalitou. Pokud jako obrázek nezvolíte něco velikosti poštovní známky, ale třeba nějakou fotku, budete mít dva různé obrázky, s různými informacemi – a do toho rozdílu by se vám hashů vešlo spousta. Když se ale na ty obrázky podíváte, na první pohled nepoznáte žádný rozdíl.
-
Jakožto dlouhodobý uživatel vizuálních hashů v SSH prostě nemůžu souhlasit se zde uvedenými argumenty.
Já na svém nic moc notebooku umím vyrobit 44 miliard klíčů za den. Porovnání randomartu asi taky chvíli zabere, na druhou stranu bych to mohl pustit na GPU, kde to bude o několik řádů rychlejší. Dokážeš rozlišit bilion obrázků?
-
To že je běžný hash také „vizuální“ je pěkná blbost, protože ho musím prvně přečíst, pak pochopit...
Ehm, co presne chcete na tom hashi chapat?
-
To je ovšem jenom chyba v pozorování. Zkusil podstrčil vám někdy někdo podobný obrázek, jestli byste si všiml rozdílu? Nezkusil. Kdybyste si to vyzkoušel, nestačil byste se divit, u jak rozdílného obrázku jste si stále ještě myslel, že je to ten, který si pamatujete. Zvlášť když očekáváte, že by to měl být ten samý obrázek.
Zde se ovšem bavíme o zcela specifickém algoritmu na generování obrázků, který je zkonstruován tak, aby k tomuhle nedocházelo, ne o nějaké krajinomalbě. Například ten SSH fingerprint a jeho Drunken bishop (http://dirk-loss.de/sshvis/drunken_bishop.pdf).
Já na svém nic moc notebooku umím vyrobit 44 miliard klíčů za den. Porovnání randomartu asi taky chvíli zabere, na druhou stranu bych to mohl pustit na GPU, kde to bude o několik řádů rychlejší. Dokážeš rozlišit bilion obrázků?
Rozhodně lépe, než bilion stejně-dlouhých alfanumerických stringů.
Ehm, co presne chcete na tom hashi chapat?
Abych ho mohl porovnávat, musím ho prvně přečíst. Pak ho musím udržet v paměti a pak ho musím porovnat znak za znakem s tím, který jsem tam viděl dříve. Pak musím rozhodnout, jestli je stejný.
V případě obrazu nemusím dělat tolik kroků. Možná jsem výjimka, ale dokážu prostě porovnávat dva obrazy a jejich podobnost v hlavě přímo, doslova je vidím. Stejně tak si jednodušeji zapamatuji barvy a tvar, než náhodnou alfanumerickou sekvenci znaků.
-
V případě obrazu nemusím dělat tolik kroků. Možná jsem výjimka, ale dokážu prostě porovnávat dva obrazy a jejich podobnost v hlavě přímo, doslova je vidím. Stejně tak si jednodušeji zapamatuji barvy a tvar, než náhodnou alfanumerickou sekvenci znaků.
Muzu te potesit, ze nejsi sam, ostatne prave proto mame vsude, kde je to uzitecne, obrazky: http://e-autoskola.cz/dopravni-znacky/zakazove-dopravni-znacky.php a nikoli jen tabulky s napisy :)
-
Zde se ovšem bavíme o zcela specifickém algoritmu na generování obrázků, který je zkonstruován tak, aby k tomuhle nedocházelo, ne o nějaké krajinomalbě.
„Tohle“ je vnímání obrazu lidským mozkem. Ten specifický algoritmus asi není implementován v lidském mozku, že?
Dokážeš rozlišit bilion obrázků?
Rozhodně lépe, než bilion stejně-dlouhých alfanumerických stringů.
No to určitě. Když ty stringy budou nějak rozumně zformátované, můžete je porovnávat znak po znaku. To na obrázku dokážete udělat jedině tehdy, pokud budou také zobrazovat po sobě jdoucí symboly. Lépe se to bude porovnávat, pokud použijete nějaké symboly, které už člověk zná, z jedné množiny, takové, které umí snadno pojmenovat. Jaká je největší množina takových znaků? Ano, alfanumerické znaky.
Abych ho mohl porovnávat, musím ho prvně přečíst. Pak ho musím udržet v paměti a pak ho musím porovnat znak za znakem s tím, který jsem tam viděl dříve. Pak musím rozhodnout, jestli je stejný.
Nemusíte. Když si přečtete zadání, ty dva obrázky mají být zobrazené vedle sebe. Takže si přečtete nějakou skupinu znaků, kterou si snadno zapamatujete, porovnáte s druhou stranou. A pokročíte na další skupinu znaků. Obrázek takhle dokážete porovnat jedině tehdy, pokud bude zobrazovat posloupnost symbolů. V opačném případě si totiž už po prvnímporovnání nebudete pamatovat, kde jste vlastně skončil.
Možná jsem výjimka, ale dokážu prostě porovnávat dva obrazy a jejich podobnost v hlavě přímo, doslova je vidím.
Jedině že byste měl fotografickou paměť. Jinak na těch obrázcích dokážete porovnat pár znaků – jednotky, nanejvýš nízké desítky. K čemu bude nějaký šestibitový hash?
-
Co si místo píčovin najít ženskou ?
-
Co si místo píčovin najít ženskou ?
No a ty ženskou máš? Pokud jo, tak to nefunguje, protože píšeš píčoviny do diskuze. Pokud ne, tak tvůj názor nemá žádnou hodnotu, protože kážeš vodu a piješ víno.
-
Abych ho mohl porovnávat, musím ho prvně přečíst. Pak ho musím udržet v paměti a pak ho musím porovnat znak za znakem s tím, který jsem tam viděl dříve. Pak musím rozhodnout, jestli je stejný.
V případě obrazu nemusím dělat tolik kroků. Možná jsem výjimka, ale dokážu prostě porovnávat dva obrazy a jejich podobnost v hlavě přímo, doslova je vidím. Stejně tak si jednodušeji zapamatuji barvy a tvar, než náhodnou alfanumerickou sekvenci znaků.
No jenže string právě znak po znaku porovnávat nemusíte. Snadno poznáte, zda jsou dva verše stejné:
Ach Romeo, Romeo! Proč jsi Romeo?
Své jméno zapři, odřekni se otce.
versus
Co je to, Montek? Ruka ne, ni noha,
ni paže, ani tvář, ni jiná část.
Takže by šlo využít právě výňatky z literatury. Není to geniální?
Jinak skutečně existují anomálie, které některým lidem umožňují vizuální operace provádět přímo v představě - bez nutnosti si cokoli vizualizovat na papíře. Ale jsou velmi vzácné, není to nic, na čem byste mohl založit aplikaci pro neznámé uživatele.
O.
-
No jenže string právě znak po znaku porovnávat nemusíte. Snadno poznáte, zda jsou dva verše stejné:
Ach Romeo, Romeo! Proč jsi Romeo?
Své jméno zapři, odřekni se otce.
versus
Co je to, Montek? Ruka ne, ni noha,
ni paže, ani tvář, ni jiná část.
Takže by šlo využít právě výňatky z literatury. Není to geniální?
To jako, ze do toho programu prepisete celeho Shakespeara a nekolik knihoven krasne literatury navic, rozsekate to na dvouradkove useky a kazdemu moznemu hashi priradite jeden z tech useku? Uzivatel pak snadno pozna kus Shakespeara od Cernych baronu. Tak sha-256 je to, co tazatel pouziva, jestli se nemylim. 2^256=1.15792089237e+77 (za predpokladu, ze vsechny kombinace jsou mozne jako vystup z sha-256, coz nevim). Tak tolik dvojradkovych rikanek by se do telefonu neveslo. Navic si nejsem jist, jestli mame k dispozici dostatek literatury, i kdybychom zahrnuli i tu, kde ani nedokazeme pojmenovat pismo, Rude pravo a Leninovy spisy.
A kdyz ten hash rozsekate napriklad po dvou bytech a priradite ke slovniku 2^16 slov, tak vam z toho zase nepoleze Shakespeare, ale nahodna poezie stylu:
Ach hrnec motor kun bezi vesmir hovno,
Soustruh laska hoblovat tuberkuloza zeleny zehlicka.
-
No jenže string právě znak po znaku porovnávat nemusíte.
Asi ti vezmu iluze, ale SSH fingerprint vypadá takhle:
43:51:43:a1:3a:fc:8b:b7:04:65:a9:b1:0f:66:73:a8
Schválně si ho zkus zobrazit na mobilu a pak porovnat třeba s tímhle: http://pastebin.com/ks4mQGY3
Zábavné, že?
Takže by šlo využít právě výňatky z literatury. Není to geniální?
Geniální nápad s Shakespearem uznám tehdy, až ho uvidím v praxi. Bitcoin takhle umožňuje zálohovat třeba peněženku, ale je to krapet dlouhé a problém s porovnáním dvou stringů moc neodpadává.
-
Ano, samozřejmě, ten můj nápad stojí nebo padá na tom, jak velké množiny se na sebe mapují. To samé ale platí i pro tu vizualizaci.
Určit velikost těch množin asi nebude triviální, protože velikost použitelných množin závisí na rozpoznatelnosti prvků množiny člověkem. To je ta komplikace v porovnání s použitím běžného člověkem obtížně čitelného textového hashe (a motivace původního tazatele je právě „zlepšit čitelnost hashe“).
Pokud potřebný objem literatury byl moc objemný, šlo by ji skutečně generovat - akorát by se zhoršila srozumitelnost („čitelnost“).
Hezké téma na menší výzkum :-)
-
Pokud potřebný objem literatury byl moc objemný, šlo by ji skutečně generovat - akorát by se zhoršila srozumitelnost („čitelnost“).
Tim si moc nepomuzu. Rekneme, ze pouziji vzdy dva bajty jako index ve slovniku. To mi dela 65536 slov, pricemz bych, kvuli uspore mista, volil slova kratsi. To je porad ale dost k nicemu, protoze misto 64 znaku hexa vypisu budu porovnavat 16 nesmyslnych slov. Pri volbe 3 bajtu mi zase ten slovnik dost naroste. V realu by to sice bylo par MB textu, ktery by navic sel asi komprimovat, ale kdo se s tim slovnikem ma setavovat? Zejmena, kdyz by mel zarucit, ze nebude obsahovat podbna slova, ktera by se mohla plest. 4 bajty by znamenaly porovnavat uz jen 8 slov, ale ten slovnik by byl uz jak belgicka krava.
-
Ale šel by použít kratší hash (navrhoval jsem SHA-3, kde si mohu sám volit délku) - za cenu pravděpodobnější kolize. Jelikož ta metoda stejně nemůže být 100% spolehlivá, nemuselo by to zas tak vadit.
Logika věci je totiž asi následující: Většina uživatelů žádné hashe nekontroluje, protože to je moc pracné. Pokud kontrolu usnadníme a uděláme zábavnější, bude ji kontrolovat více lidí a celkově to bude pro bezpečnost přínosné a to dokonce i pokud kontrola v jednotlivých případech selže (původní tazatel sice chtěl řešit nějakou aplikaci a kontrolu čárových kódů, ale princip zůstává, stačí nahradit "bezpečnost" za "naskenování správného kódu").
Ještě by šlo nahradit hash nějakou monotónní vzestupnou řadou, kde by člověk jen ověřil číslo (id toho záznamu). Musel by ale někde být centrální index všech hashů (resp. těch záznamů). Pak by to bylo podobné jako zkontrolovat číslo účtu na které posílám přes internetové bankovnictví peníze.
-
Nebolo by jednoduchsie keby tie dva hashe porovnal software a uzivatelovy iba vypisal ci je to OK alebo Fake?
-
To zadání je přibližně tak, že jeden hash je na papíře a druhý na displeji a uživatel to má porovnat.
-
osobne by mi nejvic vyhovovalo audio - tj. ze by ten hash "neco" z displeje diktovalo a je bych to podle diktatu kontroloval "na papire"
v js to ?asi nepujde? ale pres skript/sluzbu na serveru by to jit melo (samozrejme nastane problem, kdyz zarizeni nema audio vystup)
-
To je dobrý nápad, navíc audio výstup není problém - čtení textu počítačem funguje i offline spolehlivě, zvlášť pokud mohu omezit množinu vstupních textů.
-
a co ten hash rozsekat na kusy a podle vzniklých parametrů generovat počítačovou grafikou lidské obličeje? na rozpoznávání ksichtů mají lidi už od malička dobře vytrénované obvody v hlavě..
jo, ale před vygenerováním je potřeba se uživatele zeptat, jaké je rasy. aby mu pak různé hashe nepřipadaly stejné.
-
Je to zatím na vodě, to je jasné, chce to na tom zapracovat. Ale ten azimut je prostě super :)
Po přečtení o azimuthu jsem si okamžitě vzpomněl na pythoní turtle grafiku ;) a sesmolil tento skriptík:
#!/usr/bin/python3
import turtle
hash = 'ea7e4017f6d750b4c5fcbcb9c9c491181bbed0a24b91bf748d391b2097a0d444'
scale = 5
window_size = 450
def splitter(seq,n):
while seq:
yield seq[:n]
seq = seq[n:]
bob = turtle.Turtle()
turtle.screensize(window_size,window_size)
turtle.colormode(1)
bob.width(5)
for a,b in splitter(hash,2):
ia = int(a,16)
ib = int(a,16)
bob.right(22.5*ia)
bob.forward(ib*scale)
bob.pencolor(ib/16,ia/16,.5)
turtle.mainloop()
Z pokusů je zřejmé, že jsou tam mezery. Například při změně sudého znaku hashe se změní jen barva a délka, což není na zběžný pohled jasné.
-
Chtěl bych nějak vizualizovat kryptograficky otisk (hash) zprávy. Nějak pěkně graficky, aby uživatel snadno na první pohled dokázal porovnat dva otisky a snadno se přesvědčit, že jsou stejné. Neměl by někdo nějaký nápad? Třeba nějaké náhodné malování na canvas?
Příklad, když uživatel uvidí na obrazovce obrázek divného stromečku a na mobilu stejný obrázek divného stromečku (tedy vygenerovaný obrázek), pochopí, že na mobilu má stejný otisk jako na obrazovce počítače.
Ideálně by bylo, aby se jednalo o kresbu, nejlépe monochromatickou. S barvama je potíž, lidi bejvají barvoslepí.
Nějaké fraktály? Ale zase aby se to počítalo rychle, ideálně v JS
Proc vymyslet kolo?
http://www.netsec.ethz.ch/publications/papers/validation.pdf (http://www.netsec.ethz.ch/publications/papers/validation.pdf)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.2948&rep=rep1&type=pdf (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.2948&rep=rep1&type=pdf)
http://www.researchgate.net/publication/2593943_Hash_Visualization_a_New_Technique_to_improve_Real-World_Security (http://www.researchgate.net/publication/2593943_Hash_Visualization_a_New_Technique_to_improve_Real-World_Security)
https://www.secuso.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_SECUSO/Theses/BA/Visualization_of_Hash-functions.pdf (https://www.secuso.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_SECUSO/Theses/BA/Visualization_of_Hash-functions.pdf)
a hlavne
http://dirk-loss.de/sshvis/drunken_bishop.pdf (http://dirk-loss.de/sshvis/drunken_bishop.pdf)
-
Jo když vidím ty obrázky v Visualization_of_Hash-functions.pdf tak si říkám, že se bude uživatel cítit jako u psychologa, který zkoumá jeho kognitivní schopnosti
„...a předložili opici tři různé kostičky a banánem ji motivovali, aby stiskla odpovídající tlačítka...“
:-D :-D :-D
-
Jo když vidím ty obrázky v Visualization_of_Hash-functions.pdf tak si říkám, že se bude uživatel cítit jako u psychologa, který zkoumá jeho kognitivní schopnosti
„...a předložili opici tři různé kostičky a banánem ji motivovali, aby stiskla odpovídající tlačítka...“
:-D :-D :-D
Jo, obrazky jsou vtipne :)
Ale v te diplomce je sousta odkazu na jina reseni a jsou tam i uvedena. Napr. vlajky na strane 17 mi prijdou docela fajn.