Vlákno názorů k článku
DiceKeys: silné heslo na celý život
od Heron - Dohromady dostanete entropii více jak 196 bitů.
No on...
-
Dohromady dostanete entropii více jak 196 bitů.
No on ve videu píše 128b-196b. A to je málo. Díky narozeninovému paradoxu se to dá s padesátiprocentní úspěšností lousknout už po 64b-98b pokusech. Minimální síla se dnes uvádí 112b (224b) a standardem je 128b (256b). Proto máme AES256, SHA3-256 atd.
Určitě je to lepší řešení než jiné generátory hesel (ve skutečnosti je to velmi pěkný nápad), ale asi bych tomu neříkal jedno heslo na celý život nebo na dekádu. To by muselo být větší (což ale není takový problém).
Heslo na úrovni dnešní krypto by mělo mít alespoň 18 znaků (malá velká abeceda + číslice). 258b (ln(18^(26*2+10))/ln(2)). Přidáním jednoho písmenka navíc je to 62x silnější. Chce to ale dobrý generátor (a paměť).
24. 8. 2020, 12:22 editováno autorem komentáře
-
FíkZlatý podporovatelmáte to špatně spočítané, má být ln((26*2+10)^18)/ln(2)=107
navíc nevím, kde ve videu přišel na 128, správně i s orientacemi kostek to je 196, bez orientací (když by se to někomu zdálo složité) 148
-
Máte pravdu, tak dlouho jsem bojoval s bc a neexistencí factorialu, že jsem to otočil. Je to 43 znaků (l((26*2+10)^43)/l(2)). Mě se to zdálo divné, ale kontroloval jsem to s projektem s jinou abecedou. I mistr tesař se utne.
Jak přišel na 128 netuším. Co mě ale dráždí víc, je fakt, proč je to 196b a ne 256+. Kdyby to měl jako 6x6 (36 kostek) tak mu vychází luxusních 301b entropie (l(fac(36)*24^36/4)/l(2)).
-
No to záleží na tom, na co chcete útočit (nebo před jakým typem útoku se chránit). Pokud budete útočit na jeden konkrétní účet, tak ano, musíte projít všechny kombinace (tj 50% je (2^n)/2). (Kolize druhého řádu.)
Pokud ale máte zašifrovaná data z nějaké služby a máte tam všechny účty světa, a chcete z toho dostat alespoň něco, tak se to mění na 2^(n/2). (Kolize prvního řádu.)
Ale jako uživatel bych si moc nevybíral. Není důvod nepoužít kryptograficky silné heslo.
-
J ouda (neregistrovaný)
A v čem mi (s alepoň trochu realistickým šifrovacím schématem) pomůže že vím, že Alice a Bob mohou mít stejné heslo, když neznám ani jedno z nich?
Bojím se že vzoreček máte dobře, ale v dané situaci nelze použít - těch 2^(n/2) je šance že je tam _jakákoli_ kolize. Ale Vás zajímají jen kolize mezi m uživateli a n pokusy na lousknutí, nikoli všechny kolize v n. A protože m~2^20, n~2^6x, pak je zřejmé že ta šance bude proti birthday paradoxu mizivá.
-
Tak to je asi o definicích. Protože obvykle se šifrovací schema považuje za prolomené ve chvíli, kdy je nalezena libovolná kolize prvního řádu. Tj to heslo Alice nebo Boba ani nemusíte znát, ale víte že je stejné (nebo vede na stejný otisk). Třeba to víte díky slabému klíči (nebo v tomto případě heslu).
A z toho se odvozuje kryptografická síla. Pokud vím, tak brute force metodou se už hodně dávno (v devadesátkách) podařilo cracknout 96b. V roce 2013 byla minimální krypto síla nastavena na 112b. Co se podařilo brute force od té doby nevím, ale dneska je standardní krypto síla 128b. Tj 256b.
Tj v zásadě cokoliv pod 128b (256b) můžete v klidu odmítnout. A já nevím co se louská dneska (jestli je to 105b nebo tak něco) a celkem mě to nezajímá.
A já chápu, že intuitivně požadujeme nejlépe kolizi druhého řádu a to ještě navíc na konkrétní klíč. Ale takto se krypto nestaví (nebo takto mě to nikdo neučil). Krypto se staví na zabránění i hypotetickým kolizí prvního řádu a to nejen na základně oslabení funkce (tam je to končená), ale i díky slabé síle.
Proto mě to tak dráždí. Jasně, tohle kostičkové řešení je nesrovnatelně lepší než jakékoliv lidské heslo, o tom žádná, ale mohli to posunout do oblasti nad 256b (což by šlo velmi snadno).
-
Ale no tak... v tom prvním příspěvku jste napsal jasně: "Díky narozeninovému paradoxu se to dá s padesátiprocentní úspěšností lousknout už po 64b-98b pokusech." a to prostě není pravda. Stane se, tak to holt přiznejte, nevymýšlejte krkolomné výmluvy a můžeme jít dál. Jak říká staré úsloví: čím víc se v tom budete šťourat, tím víc to bude smrdět.
-
J ouda (neregistrovaný)
Ještě doplním - ony ty bity jsou opravdu docela ošemetné. Někdy v době ne zase tak nedávné kdy se vedly boje kolem legality silných šifer, tak si pamatuji (bohužel se mi tu publikaci nedaří teď dohledat) že nějaký kryptolog přišel s nápadem "secure 40bit cipher". - celé to bylo založené na tom, že v prepare fázi se z klíče velmi pomalu, ale pořád na PC dosažitelně odvozoval řádově gigabajt dat způsobem co nešel rozumně paralelizovat, které následně používala samotná bloková šifra - a ta byla opět navržena tak, aby z nich většinu potřebovala (takže byste potřeboval předpočítat a uchovávat 2^40 GB dat abyste mohl efektivně šmírovat).
Sice to bylo na naše poměry neskutečně pomalé, ale zadání (efektivně zabezpečit občanovi třeba email před vládou tak, aby bylo ekonomicky nereálné ho dešifrovat bez porušení navrhovanáho zákona) to splňovalo.Jasně že to nebylo optimální řešení a pokud by se historie obrátila tímto směrem, nejspíš by se prosadilo něco jiného (steganografie tehdy už byla dobře známá), ale jako argument do diskuse na téma že bity bez kontextu nejsou všechno to myslím postačí.
-
Moment, uvědomujete si, že se nebavíme o hashi
Uvědomuju, ale nepřijde mi na tom nic špatného. Ten secret se stejně v následujícím kroku zahashuje, nebo se použije pro nějakou key derivation fci. V nejhorším případě ten secret bude jen "zbytečně" dlouhej, což ničemu nevadí.
Jako já nehledám nějakou minimální bezpečnou délku, ta mě prostě nezajímá. Já si věci zjednodušují tím, že 256+ je vyhovující a to že to někde bude "zbytečně" velké je celkem jedno.
secure 40bit cipher
Zkuste ten paper najít, protože 40b nemůže být secure, když se vám libovolný vstup zašifruje do jednoho z 2^40 výstupů.
Jinak popisem to trochu připomíná PBKDF2. Tam se taky doufá, že mnohonásobnou iterací se to dostatečně zpomalí.
-
J ouda (neregistrovaný)
ad 256bit entropie = OK. Jakmile narazíte na praktické otázky (jako potřeba aby to uživatel vyťukal bez překlepů, aniž by měl tendence to copypastovat z texťáku na ploše, nebo po síti jak se vejít do jednoho paketu na ethernetu), tak to tak úplně jednoznačné není.
ad.40bit - to je ale délka klíče, ne délka bloku dat. 2^40 je pouze možých zobrazení nějakého nespecifikovaného bloku na sebe, ale ten může být klidně 512bytes sektor a pak good luck.
Zkusím to ještě najít někde v bordelu na disku.
-
J ouda (neregistrovaný)
Sakra nenechá mě to edit, tak znova :(
ad kolize - základní protiargumenty.
- Pokud to použijete na online službě, proč by hledali kolize když si to heslo v cleartextu vytáhnou přímo z formuláře?
- Pokud službě věříte, a akorát jí uteče databáze, tak to bude nějak osolené -> zase kolizi nenajdete.A když to použijete lokálně jako master password ke klíčence, tak tam se to stejně nějak používá k rozšifrování hlavního klíče té klíčenky, kolize s jiným heslem někde ve světe opravdu není relevantní. Jediné na čem záleží je odolnost proti BF.
A ve chvíli, kdy cena za brute force je vyšší než cena za 0day exploit na zařízení co používáte, tak opravdu netřeba řešit jestli tam máte entropii 80 nebo 280 bitů. Nebo k Vám namontovat kamerku. A nebo další side channel https://xkcd.com/538/ -
- Pokud to použijete na online službě, proč by hledali kolize když si to heslo v cleartextu vytáhnou přímo z formuláře?
- Pokud službě věříte, a akorát jí uteče databáze, tak to bude nějak osolené -> zase kolizi nenajdete.Závidím vám váš optimismus :-) I ve druhém případě, pokud to má služba v salted hash, tak jí (nebo nějakému útočníkovi) to vůbec nebrání mít ještě někde vedle plain text.
Používání hesel pro přihlašování je vůbec peklo. Lze používat klíče. Podpora pro to je (ve webserverech i browserech). Lze dosáhnout PFS. Přihlášení se na stránku by bylo stejné jako přihlášení se k ssh. Klíčů můžete mít hromadu a velikost klíče předčí jakékoliv heslo. Ne, místo toho se používají hesla jak za krále klacka. Nebo ještě hůře, aktuálním morem je nasazení "SSO" s loginem na FB nebo na Google. Máme tady standard OpenID, lze provozovat vlastní server, ale nemáte ho kde použít, protože všude je klasický password login nebo FB / Google.
to je ale délka klíče
Jasný, to ale znamená jen 2^40 pokusů o dešifrování (a rozpoznání otevřeného textu). Což je trivka. Chápu, že to obalil "strašně časově náročnou fcí" (což je přístup stejnej jako u PBKDF2), ale na velikosti klíče to nic nemění.
