Hlavní navigace

Vlákno názorů ke zprávičce Velmi rychlá kryptografická hašovací funkce BLAKE3 vyšla ve verzi 1.0.0 od anonym - "potřebujete rychlou kontrolu integrity souborů" Proč se kryptografické hashe...

  • 27. 7. 2021 9:07

    bez přezdívky

    "potřebujete rychlou kontrolu integrity souborů"

    Proč se kryptografické hashe doporučují používat ve funkci kolizních hashů? Ty mají jiné požadavky (unikátnost vs bezpečnost vs rychlost). Je nějaký jiný důvod než ten, že autoři podobných výroků o hashích, a rozdílech mezi nimi, moc neví?

  • 27. 7. 2021 9:58

    Filip Jirsák

    Co je „funkce kolizních hashů“? Požadavek na kryptografický hash je ten, aby byl pro myslitelné vstupy unikátní a nebylo možné na základě hashe vytvořit odpovídající vstup, a dále aby byl výstup distribuován náhodně. Z praktických důvodů je pak vhodné, když je ta funkce co nejrychlejší. Kromě té náhodné distribuce jsou to stejné požadavky, které mám na hash kontrolující integritu souborů.

  • 27. 7. 2021 11:39

    bez přezdívky

    A, další takový. Není algoritmus jako algoritmus, že? Vhodnost jejich použití se liší dle priority a užití, že? Viz třeba základní školní úlohy na výběr vhodného algoritmu třídění.
    A při hledání unikátnosti souboru opravdu nemá prioritu řešit bezpečnost. A existují mnohem vhodnější (rychlejší, náhodnější) hashe. Zkuste do svého oblíbeného vyhledávače zadat "non cryptograhic hash" a otevře se vám, nejspíš, úplně nový svět.

  • 27. 7. 2021 13:12

    Michal Kubeček

    Ono je to složitější. Na první pohled by se třeba zdálo, že pro nekryptografické použití (filesystém, různé hashovací tabulky, TCP ISN, …) až tak moc nevadí, když půjde relativně snadno generovat kolize. Jenže už mockrát se v podobných případech ukázalo, že taková "levnější" hashovací funkce mohou být otevřená vrátka pro DoS útoky.

  • 28. 7. 2021 8:29

    bez přezdívky

    Zrovna u těch hashovacích tabulek se jako ochrana proti DoSům využívá toho, že ten hash může být unikátní jen v rámci jednoho běžícího procesu. Vůbec není potřeba, aby jiný proces zahashoval stejná data stejně. Pak se kolize generují výrazně obtížněji.
    Neexistují nějaká univerzální kritéria pro dobrý hash. Co se hodí v jedné úloze je jen zbytečné omezení někde jinde.

  • 28. 7. 2021 8:44

    Michal Kubeček

    Zrovna u těch hashovacích tabulek se jako ochrana proti DoSům využívá toho, že ten hash může být unikátní jen v rámci jednoho běžícího procesu.

    Pokud to tak je - což dost často není pravda. Třeba v jádře to tak není skoro nikdy.

  • 28. 7. 2021 9:16

    Filip Jirsák

    dw: Čemu to vadí, když hash používáte třeba pro rychlý přístup k datům ve slovníku (hashovací tabulce)? Třeba v dynamicky typovaných jazycích (JavaScript, Python, PHP) bývá slovník jedna z nejpoužívanějších datových struktur. Přitom ten hash je jen interní způsob implementace slovníku, často se k němu z toho jazyka vůbec nedostanete.

  • 28. 7. 2021 13:18

    dw

    To samozrejme, nevadi. Je pouzivany napr aj pre git (merkel tree), pripadne join ak nevyhovie kryci index pretoze hash merge ma lepsiu cenu...

    Akurat ze data ktore dostanem zo slovniku, by mali byt tie ktore pozadujem a nie nahodna polozka. A to aj v pripade ze ten algoritmus mam vo viacerych vlaknach a ten slovnik ulozeny v shm.

    Btw, pre pobavenie. Phpkari slovnik povazuju za pole, pretoze to tvorca php nazval array. Drviva vedsina si neda vysvetlit ze je to vlastne slovnik a pole je nieco ine. Trpia tym hlavne uzivatelia nette...

  • 28. 7. 2021 13:31

    Filip Jirsák

    Takže když bude hash vypočítaný v jednom procesu jiný, než hash vypočítaný v jiném procesu, ničemu to nevadí, protože ten hash nikdy proces neopustí. Pokud se v tom procesu používá ve více vláknech, musí být ve všech vláknech stejný – ale to není v rozporu s původním komentářem.

  • 28. 7. 2021 14:00

    Filip Jirsák

    Nemusíte. Za prvé, to že jiný proces může vracet pro stejný vstup jiný hash, neznamená, že musí vracet jiný. Za druhé, řeč byla o tom, že to v některých případech nevadí. Programátor by měl být svéprávný a vědět, jak bude hashovací funkci používat a podle toho vhodnou hashovací funkci vybrat.

  • 28. 7. 2021 9:22

    Michal Kubeček

    Algoritmus ktory da pre zhodne data v jednom procese iny hash ako v inom procese

    To samozřejmě není algoritmem, prostě se k hashovaným datům přidá salt, přičemž každý proces má vlastní.

  • 28. 7. 2021 9:36

    bez přezdívky

    Jop, každopádně v téhle chvíli není pro odolnost proti dosování skrz kolize používat výpočetně náročný kryptografický hash, ale stačí něco výrazně jednoduššího a rychlejšího.

  • 28. 7. 2021 13:09

    dw

    To ano, ale ten salt sa uklada spolu s hashom. Potom sa data osolia ulozenym saltom a hash musi suhlasit. Napr hesla sa tak ukladaju uz davno. Koli tomu aby nesli pouzit rainbow tabulky...

  • 28. 7. 2021 15:18

    bez přezdívky

    Bacha, v případě hashování pro účely tabulek je to solení naprosto skrytý implementační detail. A ta sůl se s hashem neukládá.
    Např std::hash v c++ má specifikované že musí pro stejný vstup vrátit stejný hash v rámci stejného procesu. Pokud se autoři rozhodnou dodat variabilitu mezi běhy, tak jim nikdo neříká jak toho mají dosáhnout. Z veřejného api nejde zjisti ani jestli tam nějaká sůl je, natož jak ji vyčíst.

  • 28. 7. 2021 15:44

    dw

    I ked je to skryte, tak pricetny programator dufa ze napr. sha256 je jedena funkcia a zo std::hash je ta funkcia volana a rovnako je volana funkcia pre pripadne solenie. Nie ze je tam duplicitny kod pre pripadne solenie a duplicitny kod pre vypocet hashu s osolenych dat...

  • 28. 7. 2021 16:10

    Filip Jirsák

    Panečku, to je síla myšlenky. Přestože tu nikdo takový nebyl, lazywriter psal tak dlouho lidech, kteří neznají jiné hashovací funkce, než kryptografické, až se tu jeden takový dw zhmotnil.

  • 28. 7. 2021 16:49

    dw

    kludne tam moze byt i mod 32, pripadne crc32. Kryptograficke hashe maju oproti inym hashom naviac tu vlastnost ze su bezpecnejsie :D ostatne vlastnosti zostavaju. Napriklad aj ta ze hash('abc') == hash('abc').

    Dalsia diskusia o tom ze ak ma funkcia v nazve hash, tak to este neznamena ze ma vlastnosti hashovacej funkcie je tu https://www.root.cz/zpravicky/rychla-kriptograficka-hashovaci-funkce-blake3-vysla-ve-verzi-1-0-0/1073092/

    28. 7. 2021, 16:52 editováno autorem komentáře

  • 28. 7. 2021 22:03

    bez přezdívky

    Ehm. Kryptografické hashe jsou výrazně bezpečnější proti některým útokům, ale platí se za to. Žádná z mně známých C++ knihoven neimplementuje std::hash pomocí kryptografického hashe. Ostatní vlastnosti totiž nezůstávají a ta cena je nepříjemně vysoká.

    Hash je obecný název pro jakoukoliv funkci, která mapuje libovolně velká data na výstup fixní velikosti. Další požadavky jsou více či méně obvyklé, ale nejsou nezbytné.

  • 28. 7. 2021 18:01

    Michal Kubeček

    Bacha, v případě hashování pro účely tabulek je to solení naprosto skrytý implementační detail. A ta sůl se s hashem neukládá.

    Ano, asi jsem měl místo "salt" použít (v tomto kontextu) obvyklejší výraz "secret". Možná bych tím malinko snížil míru všeobecného nedorozumění v této diskusi. Tak se to pokusím aspoň trochu napravit.

    To, co jsem měl na začátku na mysli, jsou hashovací tabulky používané k rychlému vyhledávání položky; z hlavy třeba socket lookup nebo ARP cache. Z klíče se spočítá hash, vezme se zbytek při dělení velikostí tabulky (obvykle mocnina dvou) a ten se použije jako index do pole, kde je hlava jednosměrného spojového seznamu. Velikost tabulky je většinou volena tak, aby ty spojové seznamy nebyly moc dlouhé (ideální délka je 0-1). Samozřejmě také chceme, aby hashovací funkce byla co nejrychlejší a kryptografická kvalita nás teoreticky až tak nezajímá.

    Problém nastane v okamžiku, kdy bude útočník, lokální nebo i vzdálený, schopen generovat větší množství klíčů se stejným hashem (nebo jeho použitou částí), protože nás pak donutí vyrobit si nad konkrétním prvkem pole dlouhý řetěz a ten se při lookupu, který se trefí do dané hodnoty, bude muset procházet lineárně, což zdržuje a zatěžuje procesor. Proto je žádoucí tomu zabránit, buď použitím trochu chytřejší hashovací funkce nebo tím, že se do výpočtu přidá pseudonáhodně generovaná "tajná" hodnota, kterou útočník nezná.

  • 27. 7. 2021 13:31

    Filip Jirsák

    Z vašeho komentáře jsem se nedozvěděl nic, co nevím.

    Zajímalo by, mne co přesně myslíte tou bezpečností. A zejména by mne zajímaly ty ne-kryptografické hashe, které jsou náhodnější než kryptografické hashe. Když přihlédnu k tomu, že ideální kryptografický hash je orákulum, které generuje absolutně náhodný hash a pro každý vstup si vygenerovaný hash zapamatuje (a použije ho, pokud dostane stejný vstup), plyne mi z toho, že podle vás existují nekryptografické hashe, které jsou pro kryptografii vhodnější, než kryptografické hashe.

    Mimochodem, nikdo neřeší unikátnost souboru. Ve zprávičce bylo napsáno „integrita souboru“ a myslí se tím, to, že když např. stáhnu soubor z internetu, chci ověřit, že je shodný s tím, co autor na internet vystavil. Což právě řeší kryptografické hashovací funkce, které zajišťují i tu bezpečnost, tedy odolnost proti generování kolizí – tedy že mi útočník nepodstrčí upravený soubor, který ale bude mít stejný hash, jako originál.

  • 27. 7. 2021 23:54

    bez přezdívky

    Z vašeho komentáře to tak nevypadalo.

    "ideální kryptografický hash" .. možná ve vašem ideálním světě to platí. V tom skutečném mají kryptografické hashe horší vlastnosti při použití pro jiné účely (vyšší pravděpodobnost kolize a/nebo nižší rychlost). Ten dotaz do vyhledávače opravdu není těžké napsat :)

    "vygenerovaný hash zapamatuje" lol, máte alespoň vzdálené tušení, jak fungují hashovací algoritmy? Opravdu si myslíte, že tam jde o nějaké zapamatování?

    Ve zprávě se píše "Pokud tedy potřebujete ..". Tím, že si stáhnete nějaký soubor a u něj si uděláte checksum, tak tím bezpečnost nezvýšíte :) Hint: pokud by ve článku bylo "Pokud začnou distrubutoři software používat tento hash" .. tak by to možná začalo dávat smysl.

    27. 7. 2021, 23:57 editováno autorem komentáře

  • 28. 7. 2021 8:57

    Filip Jirsák

    lazywriter: Najděte si ve slovníku význam slova „ideální“.

    Ve zprávě se píše "Pokud tedy potřebujete ..". Tím, že si stáhnete nějaký soubor a u něj si uděláte checksum, tak tím bezpečnost nezvýšíte :) Hint: pokud by ve článku bylo "Pokud začnou distrubutoři software používat tento hash" .. tak by to možná začalo dávat smysl.
    Zprávička je krátký útvar, nerozepisuje se tam vše do naprostých detailů. To, že to jeden čtenář nepochopil, je holt smůla. Pro vaši informaci – zprávičku mohou číst i lidé, kteří distribuují soubory, takže se dozvědí, že mohou tenhle hash začít přidávat ke svým souborům. Dále se hashe pro kontrolu integrity souborů nepoužívají jen při stahování souborů, ale třeba také pro jejich archivaci. Dříve bylo běžné, že měl člověk na CD vypálené soubory a vedle jejich hashe, aby mohl při čtení zkontrolovat, že se soubor přečetl správně. Stejně tak se používá i dnes, akorát ty soubory máte obvykle na nějakém harddisku, případně v cloudovém úložišti. Ale ta potřeba být si dostatečně jist, že mám ten původní soubor, stále trvá.

  • 28. 7. 2021 9:23

    bez přezdívky

    Ve slovníku jsem si to schválně našel. Takže další nová informace pro vás:

    Význam: neskutečný, vysněný :)

    Dobře, tak jste to nepochopil a pořád se točíte na kryptografii. Chápu, že nutkání zaplevelit každou diskuzi je neodolatelné, ale někdy je dobré jej potlačit :)

    Tímto se ostatním omlouvám za krmení a slibuju, že s tím už končím.

    28. 7. 2021, 09:25 editováno autorem komentáře

  • 28. 7. 2021 10:29

    Filip Jirsák

    Ve slovníku jsem si to schválně našel. Takže další nová informace pro vás:

    Význam: neskutečný, vysněný :)
    Pro mne to není žádná nová informace. Já jsem to poznal hned, že jste napsal pěknou hloupost, když jste si stěžoval, že ideální hashovací funkce je nereálná. Tak teď už to víte i vy, jakou hloupost jste napsal.

    Dobře, tak jste to nepochopil a pořád se točíte na kryptografii.
    Vysvětlil jsem vám, proč se pro ověřování integrity souborů používají kryptografické hashovací funkce. Protože na to ověření integrity souboru jsou stejné požadavky, jako na kryptografické hashovací funkce, takže je zbytečné vymýšlet jiné funkce, když už pro to funkce existují.

    Tímto se ostatním omlouvám za krmení a slibuju, že s tím už končím.
    Příště raději ani nezačínejte. Bilance vašich komentářů, kdy vše, co jste napsal, je buď triviální nebo špatně, není moc dobrá.

  • 28. 7. 2021 14:01

    dw

    Hmm, pani, uz mi doslo o com to tu tocite. Kazdy hashovaci algoritmus da pre rovnake data rovnaky hash. Vzdy, aj blake. Ak si nedokazete uvedomit ze hash a solenie (sol je ukladana per proces) su dva separatne algoritmy, tak vas kod musi byt obcas kvalitny spagetak.

  • 28. 7. 2021 14:07

    Filip Jirsák

    Ne, takovýhle požadavek na hashovací funkce obecně neplatí. Často takový požadavek platí jenom pro jeden běh programu, při příštím běhu programu může hashovací funkce pro stejná data vracet jiný hash.

  • 28. 7. 2021 14:23

    dw

    Lenze ta funkcia vracia iny hash koli tomu ze pri inicializacii programu sa vygeneroval iny salt. Alguritmus pre hash musi vratit vzdy ten isty vysledok pre konkretne data. Pripadnu nahodnost tam zavadza algoritmus pre solenie. A ten nie je sucastou algoritmu pre hash.

    28. 7. 2021, 14:23 editováno autorem komentáře

  • 28. 7. 2021 14:34

    Filip Jirsák

    Ne, ta funkce nemusí používat žádný salt. Vy se stále omezujete na jediné použití hashovací funkce, ale těch použití je spousta. Hashovací funkce se může používat třeba pro slovníky (hashovací tabulky), přičemž triviální implementace hashovací funkce je taková, že vrací jako výstup referenci na sebe sama převedenou na číslo. Pro spoustu entit to funguje, splňuje to podmínky pro hashovací funkci v dané knihovně a při každém spuštění programu ta hodnota může být jiná.

  • 28. 7. 2021 15:28

    dw

    Vazne? :D hashCode je pre kazdu triedu implementovany inak, default implementovany v java.lang.Objec­t.hashCode() vola interne identityHashCode. Integer.hashCode je prepisana tak ze naproti tomu vracia hodnotu, Long.hashCode vracia hodnotu mod 32... Pre dva stringy s rovnakym obsahom dostanete rovnaky vysledok aj ked su to dva objekty alokovane na rozlicnych adresach... Teda ak vas nezaujima ci v hash tabulke existuje hash pre konkretny string tak mozete volat Object.super.hashCo­de, ale to je potom ta hash tabulka tak nejako zbytocna...

  • 28. 7. 2021 15:45

    Filip Jirsák

    Ano, vážně. Když píšu o metodě java.lang.Objec­t.hashCode(), myslím tím metodu java.lang.Objec­t.hashCode() ne jinou metodu. Takže celý váš komentář je irelevantní.

  • 28. 7. 2021 16:42

    dw

    Ta metoda je ale vhodna akurat k tomu aby ste zistil ci dve referencie neodkazuju na ten isty objekt. Ako hash je to uplne k nicomu napriek tomu ze to ma v nazve hash, pretoze pre dve rovnake spravy ulozene v dvoch objektoch bude navratova hodnota rozdielna. Iba ze by ste si chcel pomocou hash tabulky kontrolovat ci ste si nealokoval objekt na mieste uz alokovaneho objektu :D Nastastie je to metoda virtualna pracujuca s instanciou objektu a teda pre String a = 'abc'; String b = 'abc' da hashCode() rovnaku hodnotu, i ked 'a' a 'b' su dve rozdielne objekty. To sa uz da povazovat za hash, tak ako je vyznam slova hash definovany. (https://en.wikipedia.org/wiki/Hash_function#Properties)

    Zacinam byt rad ze tak masivne trolite v diskusiach, za ten pretroleny cas nemozete nic posrat. :D

  • 28. 7. 2021 16:54

    Filip Jirsák

    Vám ta funkce možná připadá k ničemu, ale běžně se používá a ve spoustě případů splňuje vše, co má. A jako hash to funguje perfektně. Třeba enum tuhle výchozí metodu používá – co přesně je na tom použití špatně, co nebude fungovat? Kterou vlastnost hashovacích funkcí ta funkce použitá pro enum nesplňuje?
    Pořád máte silné řeči, ale zatím jste jediné moje tvrzení nevyvrátil. Zato tu hojně kličkujete a když já píšu o Object.hashCo­de(), vy se neustále vyjadřujete o různých jiných metodách.

  • 28. 7. 2021 17:14

    dw

    Spatne je na nej to ze ze vymenovane hodnoty by mali byt unikatne, nieco ako enum('a','a',­'a','a') je nepouzitelne, realizovatelne pomocou Object.hashCode(), nerealizovatelne pomocou napr. String.hashCode(), Integer.hashCode() atd...

    Preco? Pretoze ak mate zoznam ('a','b','c','d') tak vam Object.hashCode() nepovie ze objekt s hodnotou 'a' tam uzmate, ale povie vam len to ze novo alokovany objekt string s hodnotou 'a' tam este nemate.

    Co sa vam na tom ako nevidi. Podla mna to vase tvrdenia vyvracia dostatocne.

    Ako uz zacinam mat toho dost. To "Pořád máte silné řeči, ale zatím jste jediné moje tvrzení nevyvrátil. Zato tu hojně kličkujete" mate v snippetoch? Ako vazne budete trolit do vtedy, nez clovek uvazi "ze cloveku nevysvetlis, ze ma obmedzene rozumove shopnosti, ak to nie je schopny koli svojim obmedzenym rozumovym schopnostiam pochopit" a nasledne sa na diskusiu vykasle. Vazne vam staci k podpore ega len tolko ze ste mal posledne slovo? Tak to na seba nie ste moc narocny, ak vam staci len tolko.

  • 28. 7. 2021 18:07

    Filip Jirsák

    dw: Víte, co je v Javě enum? Je na funkci java.lang.Enum­.hashCode() něco špatně, o čem nevědí miliony uživatelů po celém světě, kteří ji spokojeně používají? Ta funkce nesplňuje některou z vlastností vyjmenovaných na Wikipedii, které jste odkazoval?

    Jako příklad jsem uvedl kód z jazyka Java. Pokud chcete nějaké moje tvrzení vyvrátit, doporučil bych ve vašich příspěvcích neuvádět jako příklady kód, který v Javě nepůjde přeložit, např. enum('a','a',­'a','a'). Vaše tvrzení, že je takový kód nepoužitelný, je totiž pravdivé, ale nijak nevyvrací mé tvrzení. Spíš se po přečtení takového vašeho příspěvku vkrádá myšlenka, zda to ze cloveku nevysvetlis, ze ma obmedzene rozumove shopnosti, ak to nie je schopny koli svojim obmedzenym rozumovym schopnostiam pochopit není hlavně váš problém.

    Myslím si, že by se hodil takový příklad kódu v Javě, který půjde přeložit a který bude fungovat špatně z toho důvodu, že metoda java.lang.Enum­.hashCode() funguje v rozporu se specifikací nebo nesplňuje požadavky na hashovací funkci vyjmenované na Wikipedii. Pro člověka vašich znalostí by neměl být problém takový kód napsat.

    (Mimochodem, teď píšu o java.lang.Enum­.hashCode(), předtím jsem psal o java.lang.Objec­t.hashCode(). Pokud by vás napadlo, že jsem zbaběle přešel k jiné metodě, upozorňuji vás rovnou, že java.lang.Enum­.hashCode() pouze převolává java.lang.Objec­t.hashCode(). Enum jsem vybral místo Object u proto, abyste si nestěžoval, že Object nic rozumného nedělá. Enumy se v aplikacích běžně používají, mají svůj dobrý význam a běžně se vkládají do kolekcí, kvůli kterým především metoda hashCode() v Javě existuje. Sice se s enumy kvůli efektivitě spíš používá EnumSet nebo EnumMap, ale nic nebrání použít i HashSet nebo HashMap.)

  • 29. 7. 2021 2:39

    dw

    Nie je deterministicka! Hash funkcia MUSI splnat podmienku ze pre vstupnu hodnotu dostaneme vzdy rovnaky vystup.

    Deklaracia toho co je hash funkcia rozhodne nie je zavisla od toho ako je implementovana v jave.

  • 29. 7. 2021 13:53

    Filip Jirsák

    Je deterministická, jinak by to bylo k ničemu. Definice hashovací funkce rozhodně není závislá na žádné implementaci v Javě. Ale implementace java.lang.Enum­.hashCode() splňuje všeobecně uznávanou definici hashovací funkce. Stejně jako ji splňují podobné hashovací funkce v Pythonu a dalších jazycích.

    Jsem zvědav, kdy vám konečně dojde, že „stejný vstup“ je mnohem širší pojem, než si myslíte. „Stejný vstup“ nemusí znamenat jen „stejnou posloupnost bitů“. „Stejný vstup“ také může být „entita reprezentující stejnou fyzickou osobu“. Nebo „entita reprezentující stejnou fyzickou osobu v rámci jednoho běhu programu“.

    Přečtěte si ten článek na Wikipedii, který jste odkazoval – tam je to napsané.

  • 29. 7. 2021 16:45

    dw

    Nie je deterministicka. Je odvodena z adresy objektu vo VM. Po dealokovani objektov moze mat novo alokovany objekt rovnake hashCode ako niektory z dealokovanych i ked ide o uplne iny objekt. Deterministicka je napr String.hashCode. Rovnako ako pre vami spominanu fyzicku osobu bude hash deterministicky vtedy ak sa bude pocitat napr z rodneho cisla, nie z gps suradnic.

  • 29. 7. 2021 17:26

    Filip Jirsák

    Nie je deterministicka.
    Je deterministická. Po dobu běhu aplikace bude pro stejný objekt vracet stále stejnou hodnotu. Když si nějaký enum uložíte do EnumSetu, vždycky ho tam později najdete. Kdyby ta funkce nebyla deterministická, mohlo by se stát, že by se tam enum nenašel, i kdyby tam byl.

    Je odvodena z adresy objektu vo VM.
    Ano, tak jsme se k tomu dostali. Jako příklad hashovací funkce jsem uváděl funkci, jejíž výstup závisí na referenci na vstupní objekt. A pak jsem javovské hashCode() uváděl jako reálný příklad takové implementace.

    Přečtěte si konečně ten článek na Wikipedii, který jste odkazoval.

    Po dealokovani objektov moze mat novo alokovany objekt rovnake hashCode ako niektory z dealokovanych i ked ide o uplne iny objekt.
    Jinými slovy, může vzniknout kolize. Jaké překvapení.

    Deterministicka je napr String.hashCode.
    Pro tu ovšem také může vzniknout kolize. A i pro ni platí, že mezi dvěma běhy aplikace se hashCode pro stejný String může změnit. Protože způsob výpočtu hashCode pro String není v API závazně popsán, jiná implementace standardní knihovny nebo jiná implementace JVM ho může počítat jinak.

    Rovnako ako pre vami spominanu fyzicku osobu bude hash deterministicky vtedy ak sa bude pocitat napr z rodneho cisla, nie z gps suradnic.
    Když se bude hashCode počítat z rodného čísla, při změně rodného čísla osoby se vypočítá jiný hash, i když se osoba nezměnila. Vy tu funkci sice nazýváte deterministickou, ovšem ta funkce nesplňuje podmínky pro hashCode v Javě a není to hashovací funkce v tom všeobecně uznávaném významu (který je např. na Wikipedii), protože není zaručeno, že pro stejný vstup (tedy stejnou osobu) vrátí vždy stejný výstup.

  • 30. 7. 2021 4:57

    dw

    Je deterministická. Po dobu běhu aplikace bude pro stejný objekt vracet stále stejnou hodnotu. Když si nějaký enum uložíte do EnumSetu, vždycky ho tam později najdete. Kdyby ta funkce nebyla deterministická, mohlo by se stát, že by se tam enum nenašel, i kdyby tam byl.

    Nie je, pretozeto nie je hash ale referencia. Hash by to bol vtedy ak by bolo obtiazne dostat povodnu hodnotu.
    Najde, pozrite si ako je implementovana napr enum.valueOf(str), prechadza tie polozky cez for...

    Ano, tak jsme se k tomu dostali. Jako příklad hashovací funkce jsem uváděl funkci, jejíž výstup závisí na referenci na vstupní objekt. A pak jsem javovské hashCode() uváděl jako reálný příklad takové implementace.

    Tak si prejdite zdrojaky ako je Object.hashCode implementovany, je to priamo referencia, nie jej hash.

    Po dealokovani objektov moze mat novo alokovany objekt rovnake hashCode ako niektory z dealokovanych i ked ide o uplne iny objekt.
    Jinými slovy, může vzniknout kolize. Jaké překvapení.

    Asi vam nie je celkom jasne co je kolizia. Ak ma ten objekt rovnaku referenciu, tak to kolizia nie je. To je to iste ako by ste oznacil za kolizu hash dvoch rovnakych retazcov.

    Rovnako ako pre vami spominanu fyzicku osobu bude hash deterministicky vtedy ak sa bude pocitat napr z rodneho cisla, nie z gps suradnic.
    Když se bude hashCode počítat z rodného čísla, při změně rodného čísla osoby se vypočítá jiný hash, i když se osoba nezměnila. Vy tu funkci sice nazýváte deterministickou, ovšem ta funkce nesplňuje podmínky pro hashCode v Javě a není to hashovací funkce v tom všeobecně uznávaném významu (který je např. na Wikipedii), protože není zaručeno, že pro stejný vstup (tedy stejnou osobu) vrátí vždy stejný výstup.

    Ktory iny osobny udaj je u osoby nemenny. V pripade rc dochadza k zmene najzriedkavejsie. Ale vam skor evidentne unikla pointa, hodnota - rc versus referencia - poloha.

  • 30. 7. 2021 10:58

    Filip Jirsák

    Nie je, pretozeto nie je hash ale referencia. Hash by to bol vtedy ak by bolo obtiazne dostat povodnu hodnotu.
    To nijak nesouvisí s tím, na co jste reagoval. A když umíte z hashe vráceného funkcí hashCode() získat původní hodnotu, tak mi řekněte, jaká je původní hodnota objektu s hashem 7534.

    Najde, pozrite si ako je implementovana napr enum.valueOf(str), prechadza tie polozky cez for...
    Víte, jak funguje hashovací tabulka? Zkusíme malý příklad. Vypočítám hash objektu, vyjde mi 7023 a použiju to jako klíč do hashovací tabulky. Až budu chtít zjistit, zda daný objekt je jako klíč v mapě, vypočítám znovu jeho hash. Podle vás je ta funkce nedeterministická, takže mi vyjde jiný hash, třeba 16. Jak přesně podle vás bude fungovat to hledání v hashovací tabulce, abych zjistil, že tam ten klíč je?
    Jak podle vás souvisí enum.valueOf(str) s EnumSetem nebo EnumMapou?

    Tak si prejdite zdrojaky ako je Object.hashCode implementovany, je to priamo referencia, nie jej hash.
    Ano. Proto jsem ji uváděl jako příklad hashovací funkce, která je implementovaná tak, že vrací referenci.

    Asi vam nie je celkom jasne co je kolizia. Ak ma ten objekt rovnaku referenciu, tak to kolizia nie je. To je to iste ako by ste oznacil za kolizu hash dvoch rovnakych retazcov.
    Pro vaši informaci, kolize hashovací funkce znamená, že dva různé vstupy dávají stejný výstup (hash). Vy jste psal, že by byl objekt dealokován a na stejném místě v paměti by vznikl nový objekt. Máme tu tedy dva různé objekty, starý a nový. Ty objekty mají stejný hash. Takže je to kolize.

    Ktory iny osobny udaj je u osoby nemenny.
    Rodné číslo neměnné není.

    V pripade rc dochadza k zmene najzriedkavejsie.
    Aha, a podle vás je hashovací funkce definovaná tak, že jenom „najzriedkavejsie“ dává pro stejný vstup jiný výstup? Poslyšte, co kdybyste si konečně přečetl ten článek na Wikipedii, který jste sám odkazoval, abyste konečně zjistil, jaké jsou požadavky na hashovací funkci?

    Ale vam skor evidentne unikla pointa, hodnota - rc versus referencia - poloha.
    Vy v tom máte takový guláš…

  • 30. 7. 2021 17:20

    dw

    Nie je, pretozeto nie je hash ale referencia. Hash by to bol vtedy ak by bolo obtiazne dostat povodnu hodnotu.
    To nijak nesouvisí s tím, na co jste reagoval. A když umíte z hashe vráceného funkcí hashCode() získat původní hodnotu, tak mi řekněte, jaká je původní hodnota objektu s hashem 7534.

    Najde, pozrite si ako je implementovana napr enum.valueOf(str), prechadza tie polozky cez for...
    Víte, jak funguje hashovací tabulka? Zkusíme malý příklad. Vypočítám hash objektu, vyjde mi 7023 a použiju to jako klíč do hashovací tabulky. Až budu chtít zjistit, zda daný objekt je jako klíč v mapě, vypočítám znovu jeho hash. Podle vás je ta funkce nedeterministická, takže mi vyjde jiný hash, třeba 16. Jak přesně podle vás bude fungovat to hledání v hashovací tabulce, abych zjistil, že tam ten klíč je?
    Jak podle vás souvisí enum.valueOf(str) s EnumSetem nebo EnumMapou?

    Tak si prejdite zdrojaky ako je Object.hashCode implementovany, je to priamo referencia, nie jej hash.
    Ano. Proto jsem ji uváděl jako příklad hashovací funkce, která je implementovaná tak, že vrací referenci.

    No vidite ze si viete dokazat aj sam ze sa mylite :)

    Asi vam nie je celkom jasne co je kolizia. Ak ma ten objekt rovnaku referenciu, tak to kolizia nie je. To je to iste ako by ste oznacil za kolizu hash dvoch rovnakych retazcov.
    Pro vaši informaci, kolize hashovací funkce znamená, že dva různé vstupy dávají stejný výstup (hash). Vy jste psal, že by byl objekt dealokován a na stejném místě v paměti by vznikl nový objekt. Máme tu tedy dva různé objekty, starý a nový. Ty objekty mají stejný hash. Takže je to kolize.

    Kolizia v pripade hash funkcie je ak pre dva rozne vstupy dostanete rovnaky vysledok. Ak je referencia na stary a na novy objekt rovnaka, tak to nie je kolizia v hash funkcii.

    Ktory iny osobny udaj je u osoby nemenny.
    Rodné číslo neměnné není.

    Ja som netvrdil ze nemmene nie je. Vytrhol ste to z kontextu. Povodne to bolo "Ktory iny osobny udaj je u osoby nemenny. V pripade rc dochadza k zmene najzriedkavejsie.". Tak sa spytam este raz, ktory udaj okrem rc, je u osoby z najvecsou pravdepodobnostou nemenny?

    Vy v tom máte takový guláš…

    Nemam, to vy len trolite a uz sa do toho pekne zamotavate :D

  • 30. 7. 2021 17:32

    Filip Jirsák

    No vidite ze si viete dokazat aj sam ze sa mylite :)
    Já jsem napsal úplně na začátku vlákna, že některé hashovací funkce jsou implementovány tak, že vrací jen referenci na objekt převedenou na číslo. Vy jste teď po mnoha komentářích objevil, že to tak doopravdy je a potvrdil jste to. To nevypadá, že bych se mýlil, když i vy jste nakonec mé tvrzení potvrdil…

    Kolizia v pripade hash funkcie je ak pre dva rozne vstupy dostanete rovnaky vysledok. Ak je referencia na stary a na novy objekt rovnaka, tak to nie je kolizia v hash funkcii.
    Ano, správně, kolize je, když pro dva různé vstupy vrací hashovací funkce stejný výstup. Takže když hashovací funkce pro dva různé objekty vrací stejný výstup, je to kolize. To, že reference ukazuje na stejné místo v paměti, je irelevantní – jsou to dva různé objekty.

    Ja som netvrdil ze nemmene nie je.
    Chtěl jste ho použít jako vstup do hashovací funkce.

    Tak sa spytam este raz, ktory udaj okrem rc, je u osoby z najvecsou pravdepodobnostou nemenny?
    Datum narození, rodné jméno a příjmení, místo narození.

    Nemam, to vy len trolite a uz sa do toho pekne zamotavate :D
    Já se do ničeho nezamotávám. To vy tu vymýšlíte nesmysly jako že rodné číslo je hodnota, zatímco GPS souřadnice jsou reference.

  • 30. 7. 2021 18:06

    dw

    No vidite ze si viete dokazat aj sam ze sa mylite :)
    Já jsem napsal úplně na začátku vlákna, že některé hashovací funkce jsou implementovány tak, že vrací jen referenci na objekt převedenou na číslo. Vy jste teď po mnoha komentářích objevil, že to tak doopravdy je a potvrdil jste to. To nevypadá, že bych se mýlil, když i vy jste nakonec mé tvrzení p vrací jen referenci na objekt potvrdil…

    Ta funkcia vracia referenciu a nie hash. Ako ste sam potvrdil. To ze sa ta funkcia vola hashCode a vracia priamo nehashovanu referenciu, neznamena ze by to nejako menilo vseobecnu definiciu co je hash a hashovacia funkcia.

    Kolizia v pripade hash funkcie je ak pre dva rozne vstupy dostanete rovnaky vysledok. Ak je referencia na stary a na novy objekt rovnaka, tak to nie je kolizia v hash funkcii.
    Ano, správně, kolize je, když pro dva různé vstupy vrací hashovací funkce stejný výstup. Takže když hashovací funkce pro dva různé objekty vrací stejný výstup, je to kolize. To, že reference ukazuje na stejné místo v paměti, je irelevantní – jsou to dva různé objekty.

    Vstup do "hashCode" je referencia. Kolizia teda vznikla este pred pouzitim tzv. hash funkcie. Vystup je referencia, tj to iste co je na vstupe. Object.hashCode tym padom nie je hash funkcia ani omylom.

    Ja som netvrdil ze nemmene nie je.
    Chtěl jste ho použít jako vstup do hashovací funkce.

    Je vseobecne uznavane ako jednoznacne identifikujuci udaj.

    Tak sa spytam este raz, ktory udaj okrem rc, je u osoby z najvecsou pravdepodobnostou nemenny?
    Datum narození, rodné jméno a příjmení, místo narození.

    Uz vidim ako prave vam predklada kazdy overenu kopiu rodneho listu aby ste z tych udajov mohol vytvorit hash. Vacsina vas posle spatky do dob normalizacneho temna a odide tam kde bude stacit doklad s rodnym cislom.

    Nemam, to vy len trolite a uz sa do toho pekne zamotavate :D
    Já se do ničeho nezamotávám. To vy tu vymýšlíte nesmysly jako že rodné číslo je hodnota, zatímco GPS souřadnice jsou reference.

    Referencia ale je umiestnenie objektu v ramci pamate VM. Toto umistnenie nie je nemenne. Neviem ako java, ale predpokladam ze to bude rovnako umoznuje objekt realokovat. Napr string, ak k nemu pridavate znaky a nestaci mu alokovane miesto tak je bud realokovany alebo sa na pozadi vytvori nanovo a do neho sa povodny string nakopiruje. Stale to bude ten isty objekt, akurat sa zmeni referencia nan.

    Mozete si to predstavit ako domceky. Hodnota je kto sa domecku zdrzuje a referencia je kde sa domecek nachadza. Ked ludi medzi domeckami prestahujete tak sa zmeni len referencia na nich. Ti ludia sa tym nezmenia. A nezmeni sa tym ani hash ktory ich identifikuje.

    To vyznelo ako pre predskolakov, skusim trocha zlozitejsie. Mate pole objektov. V tomto pripade je referencia konkretneho objektu v poli referencia na pole + index objektu x velkost objektu. Ked ich v tom poli prestahujete (napr. sort) tak ze zmenia aj ich referencie, nie ich hash.

  • 30. 7. 2021 18:46

    Filip Jirsák

    Ta funkcia vracia referenciu a nie hash.
    Ta funkce vrací hash. Poznáte to například tak, že si otevřete tu stránku na Wikipedii, kterou jste linkoval a stále ještě nečetl, budete procházet jednotlivé požadavky na hashovací funkce a odškrtávat si, zda je funkce Enum.hashCode() splňuje. Až dojdete na konec seznamu požadavků, zjistíte, že jste si odškrtal všechny požadavky, že tudíž funkce splňuje všechny požadavky na hashovací funkci tedy je to hashovací funkce.

    Kolizia teda vznikla este pred pouzitim tzv. hash funkcie.
    Nevzniká. Vstupem té hashovací funkce jsou dva různé objekty.

    Je vseobecne uznavane ako jednoznacne identifikujuci udaj.
    Naštěstí pouze lidmi, kteří se v problematice neorientují.

    Uz vidim ako prave vam predklada kazdy overenu kopiu rodneho listu aby ste z tych udajov mohol vytvorit hash. Vacsina vas posle spatky do dob normalizacneho temna a odide tam kde bude stacit doklad s rodnym cislom.
    Ptal jste se na neměnné údaje identifikující konkrétní osobu. Tak jsem vám uvedl údaje, které se používají v systémech, které se musí umět vyrovnat s tím, že rodné číslo není ani unikátní identifikátor ani neměnný identifikátor.

    Referencia ale je umiestnenie objektu v ramci pamate VM. Toto umistnenie nie je nemenne. Neviem ako java, ale predpokladam ze to bude rovnako umoznuje objekt realokovat. Napr string, ak k nemu pridavate znaky a nestaci mu alokovane miesto tak je bud realokovany alebo sa na pozadi vytvori nanovo a do neho sa povodny string nakopiruje. Stale to bude ten isty objekt, akurat sa zmeni referencia nan.
    To je přesně ono. Nevíte, ale děláte z toho dalekosáhlé závěry. Miliony lidí na světě to používají špatně, nikdo si toho nevšiml, až vy, který o tom nic nevíte, jste objevil, že to vlastně vůbec nefunguje.

    Mozete si to predstavit ako domceky.
    Rozdíl mezi znalostmi, které tu předvádíte, a mými znalostmi, jste odhadl správně. Jenom máte špatně znaménko.

  • 30. 7. 2021 20:34

    dw

    Ta funkce vrací hash. Poznáte to například tak, že si otevřete tu stránku na Wikipedii, kterou jste linkoval a stále ještě nečetl, budete procházet jednotlivé požadavky na hashovací funkce a odškrtávat si, zda je funkce Enum.hashCode() splňuje. Až dojdete na konec seznamu požadavků, zjistíte, že jste si odškrtal všechny požadavky, že tudíž funkce splňuje všechny požadavky na hashovací funkci tedy je to hashovací funkce.

    Ak by ste si ten clanok precital sam tak sa dozviete ze veta It also excludes functions that depend on the memory address of the object being hashed in cases that the address may change during execution (as may happen on systems that use certain methods of garbage collection), although sometimes rehashing of the item is possible. funkciu Object.hashCode vylucuje ako hash funkciu.
    To ste lenivy si to precitat alebo ste tak presvedceny o vlastnej neomylnosti, ze sa domievate ze je to zbytocne si to precitat.

    Kolizia teda vznikla este pred pouzitim tzv. hash funkcie.
    Nevzniká. Vstupem té hashovací funkce jsou dva různé objekty.

    Ale vznika. Maju rovnaku referenciu. Moze sa to stat napriklad aj vtedy, ak mate malo pamate a objekty si odkladate do cache. Ked ten objekt vyberiete z cache tak si buddte isty ze bude mat inu referenciu ako mal povodne a je velmi pravdepodobne ze bude mat referenciu ako objekt ktory bol nedavno odlozeny do cache a dealokovany. Kolizia tej referencie vznikne v momente ako je ten objekt alokovany, nie ako sa domnievate ze az v case volania funkcie hashCode.

    Je vseobecne uznavane ako jednoznacne identifikujuci udaj.
    Naštěstí pouze lidmi, kteří se v problematice neorientují.

    Ludia ktori sa v problematike orientuju, napr. ochrana osobnych udajov o tom nieco vedia. Jediny pripad ked sa vam moze v doselosti zmenit RC je zmena pohlavia. To ale neznamena ze to povodne RC sa recykluje. Stale vas identifikuje ako osobu v case pred zakrokom.

    Uz vidim ako prave vam predklada kazdy overenu kopiu rodneho listu aby ste z tych udajov mohol vytvorit hash. Vacsina vas posle spatky do dob normalizacneho temna a odide tam kde bude stacit doklad s rodnym cislom.
    Ptal jste se na neměnné údaje identifikující konkrétní osobu. Tak jsem vám uvedl údaje, které se používají v systémech, které se musí umět vyrovnat s tím, že rodné číslo není ani unikátní identifikátor ani neměnný identifikátor.

    Ok tak znova otazka jak v pomocnej skole. Ktore udaje je mozne od clovaka zistit, bez toho aby nonstop so sebou nosil rodny list a su dostatocne pre jednoznacnu identifikaciu osoby?

    Referencia ale je umiestnenie objektu v ramci pamate VM. Toto umistnenie nie je nemenne. Neviem ako java, ale predpokladam ze to bude rovnako umoznuje objekt realokovat. Napr string, ak k nemu pridavate znaky a nestaci mu alokovane miesto tak je bud realokovany alebo sa na pozadi vytvori nanovo a do neho sa povodny string nakopiruje. Stale to bude ten isty objekt, akurat sa zmeni referencia nan.
    To je přesně ono. Nevíte, ale děláte z toho dalekosáhlé závěry. Miliony lidí na světě to používají špatně, nikdo si toho nevšiml, až vy, který o tom nic nevíte, jste objevil, že to vlastně vůbec nefunguje.

    Vy ste stale presvedceny o tom ze referencia na objekt je nemenna? :D

    Mozete si to predstavit ako domceky.
    Rozdíl mezi znalostmi, které tu předvádíte, a mými znalostmi, jste odhadl správně. Jenom máte špatně znaménko.

    Na uroven vasich znalosti poukazuje fakt zemiesto relevantneho argumentu pouzivate zvedsa argumentacne faily. To z vas robi akurat bezcenneho trola. Tohoto nazoru mimochodom nie som sam, staci sledovat diskusie. Tym padom hodnotenie mojich vedomosti je uplne irelevantne.

  • 30. 7. 2021 21:26

    Filip Jirsák

    Ak by ste si ten clanok precital sam tak sa dozviete ze veta It also excludes functions that depend on the memory address of the object being hashed in cases that the address may change during execution (as may happen on systems that use certain methods of garbage collection), although sometimes rehashing of the item is possible. funkciu Object.hashCode vylucuje ako hash funkciu.
    Nevylučuje. Doporučuji nastudovat význam slov „in cases that“, „may“.

    Ludia ktori sa v problematike orientuju, napr. ochrana osobnych udajov o tom nieco vedia. Jediny pripad ked sa vam moze v doselosti zmenit RC je zmena pohlavia. To ale neznamena ze to povodne RC sa recykluje. Stale vas identifikuje ako osobu v case pred zakrokom.
    Vy máte smůlu, zase jste to netrefil. Lidé řešící ochranu osobních údajů jednoznačnou identifikaci osob vůbec řešit nemusí. Řešit ji musí třeba sociálka, protože byste asi nechtěl při odchodu do důchodu zjistit, že nemáte na žádný důchod nárok, protože jste pod novým rodným číslem odpracoval málo let a staré rodné číslo byl přece někdo jiný.
    Původní rodné číslo se opravdu nerecykluje. Ovšem nové rodné číslo mpůžete dostat i v jiných případech, než je změna pohlaví. Například když se ukáže, že staré rodné číslo je špatně – např. má špatnou kontrolní číslici nebo je duplicitní.

    Ktore udaje je mozne od clovaka zistit, bez toho aby nonstop so sebou nosil rodny list a su dostatocne pre jednoznacnu identifikaciu osoby?
    Třeba otisk prstu. Ale to je trochu nepraktické. Pokud myslíte údaje, které mohou být někde napsané, tak v ČR bohužel takový údaj, který by měli všichni, nemáme. Mohli jsme takový údaj mít jako náhradu rodného čísla, ale Ministerstvo vnitra řeklo „ne“.

    Vy ste stale presvedceny o tom ze referencia na objekt je nemenna?
    Dobře, trváte na tom, že se musíte znemožnit pořádně, tak do toho. Tady máte základní použití HashSet u, který při volání contains interně volá metodu hashCode(), v tomto případě konkrétně java.lang.Enum­.hashCode(). Když tvrdíte, že je tato metoda v OpenJDK implementována špatně a nesplňuje kontrakt, doplňte kód do metody magic() tak, aby se ta chyba projevila, tj. aby assert nebyl splněn. Pokud se vám to nepodaří, je mi líto, ale pak nezabráníte tomu, aby se na závěr nevypsala smutná pravda o vašich schopnostech. V metodě magic() můžete použít jakýkoli kód z veřejného API Java SE 11, tj. žádné unsafe třídy nebo metody, žádné volání nativního kódu apod. Protože jednám fér, nemusí ten assert selhat při každém spuštění, ale stačí, když se to podaří průměrně alespoň jednou za tisíc spuštění aplikace.

    Snad tomu kódu rozumíte, víte, jak funguje hashovací tabulka a chápete, proč se v tomhle kódu ta metoda java.lang.Enum­.hashCode() volá.

    Dokud se vám nepodaří takový kód napsat, prohlašuji vás oficiálně za trolla, který nic neumí a měl by chodit kanálama. Hodně štěstí!

    public class Pokus {
     public enum Troll {
       DW, GTOR
     }
    
      public static void main(String[] args) {
        Set<Troll> setOfTrolls = Collections.unmodifiableSet(new HashSet<>(Set.of(Troll.DW, Troll.GTOR)));
        magic(Troll.DW);
        assert setOfTrolls.contains(Troll.DW);
        System.out.println("Uživatel dw ničemu nerozumí, ale nedokáže to poznat, protože ničemu nerozumí.");
      }
    
      private static void magic(Troll troll) {
        //tady se realizujte
      }
    }
  • 30. 7. 2021 22:04

    dw

    Ak by ste si ten clanok precital sam tak sa dozviete ze veta It also excludes functions that depend on the memory address of the object being hashed in cases that the address may change during execution (as may happen on systems that use certain methods of garbage collection), although sometimes rehashing of the item is possible. funkciu Object.hashCode vylucuje ako hash funkciu.
    Nevylučuje. Doporučuji nastudovat význam slov „in cases that“, „may“.

    Precital ste si tu vetu celu? Ked tak preklad: Tiež vylučuje funkcie, ktoré závisia od adresy pamäte hašovaného objektu v prípadoch, že sa adresa môže počas vykonávania zmeniť (ako sa to môže stať v systémoch, ktoré používajú určité metódy zberu odpadu), aj keď niekedy je možné opätovné prehashovanie položky.
    To co je hash funkcia naozaj neurcuje java. I ked predpokladam ze aj v jave je mozne objekty dealokovat, a uvolnenu pamat pouzit pre objekty nove.

    Ludia ktori sa v problematike orientuju, napr. ochrana osobnych udajov o tom nieco vedia. Jediny pripad ked sa vam moze v doselosti zmenit RC je zmena pohlavia. To ale neznamena ze to povodne RC sa recykluje. Stale vas identifikuje ako osobu v case pred zakrokom.
    Vy máte smůlu, zase jste to netrefil. Lidé řešící ochranu osobních údajů jednoznačnou identifikaci osob vůbec řešit nemusí. Řešit ji musí třeba sociálka, protože byste asi nechtěl při odchodu do důchodu zjistit, že nemáte na žádný důchod nárok, protože jste pod novým rodným číslem odpracoval málo let a staré rodné číslo byl přece někdo jiný.
    Původní rodné číslo se opravdu nerecykluje. Ovšem nové rodné číslo mpůžete dostat i v jiných případech, než je změna pohlaví. Například když se ukáže, že staré rodné číslo je špatně – např. má špatnou kontrolní číslici nebo je duplicitní.

    Trafil, ak mate nieco vediet o ochrane osobnych udajov tak musite vediet osobny udaj identifikovat. RC patri do kategorie osobnych udajov ktore identifikuju osobu jednoznacne.

    Ktore udaje je mozne od clovaka zistit, bez toho aby nonstop so sebou nosil rodny list a su dostatocne pre jednoznacnu identifikaciu osoby?
    Třeba otisk prstu. Ale to je trochu nepraktické. Pokud myslíte údaje, které mohou být někde napsané, tak v ČR bohužel takový údaj, který by měli všichni, nemáme. Mohli jsme takový údaj mít jako náhradu rodného čísla, ale Ministerstvo vnitra řeklo „ne“.

    Skuste dat gol bez toho aby ste posuval branky.

    Vy ste stale presvedceny o tom ze referencia na objekt je nemenna?
    Dobře, trváte na tom, že se musíte znemožnit pořádně, tak do toho.

    Preco by som si koli vam mal istalovat jdk? Mna prudi len to zemusimmat v pc 4 rozne verzie jvm, pretoze platformovo nezavysli jazyk nie je prenositelny mezi verziami vlastneho vm. Skuste nejaky normalnejsi jazyk. Som schopny vam to napisat v C, ObjectPascal, ADA, python a nim. Eiffel radsej nie, ten sa len zatial ucim.

    Uvedomte si ze svet sa neriadi podla toho ako je to implementovane v jave. Na javu kasle uz aj google a v androide ho radsej nahradilo kotlinom.

    Proste implementacia v jave nemoze urcovat co je hash funkcia a co hash funkcia nie je

  • 30. 7. 2021 22:25

    Filip Jirsák

    Precital ste si tu vetu celu?
    Ano, četl. Sice jste to přeložil, ale evidentně to stále nechápete. Vycházíte totiž ze svých mylných představ o tom, co je hashovací funkce a jak funguje JVM.

    RC patri do kategorie osobnych udajov ktore identifikuju osobu jednoznacne.
    Zjistěte si, co znamená slovo „jednoznačně“. Když mají dvě osoby stejné rodné číslo, nemůže rodné číslo identifikovat osoby jednoznačně.

    Evidentně jste začal tušit, že vám teče do bot, takže se z toho zkoušíte vykroutit. Já jsem uvedl tuhle funkci z Javy jako příklad, který splňuje všechny požadavky na hashovací funkce, neodpovídá ovšem vašim naivním představám o hashovací funkci. Vy jste začal tvrdit, že ty požadavky nesplňuje a že ta funkce podle vás nemůže fungovat správně. Takže v tuto chvíli jsem po vás chtěl jenom dokázat to, že funkce Enum.hashCode() v OpenJDK nefunguje správně. Ale tomu vy se správně vyhýbáte, protože dobře víte, že to nedokážete. Že ta funkce ve skutečnosti funguje správně, a vy vůbec netušíte proč – protože podle vašich představ o fungování JVM by fungovat neměla. Tahle hádanka má jedno řešení, které ovšem vy odmítáte vidět. To řešení je prosté – nevíte, jak funguje JVM. A nevíte, co jsou hashovací funkce.

    Pro vaši informaci, Kotlin/JVM běží také nad JVM. A používá javovskou standardní knihovnu. Takže se tam používá úplně stejné volání Enum.hashCode() a stejný HashSet a   HashMap.

    Ale když si myslíte, že umíte Python, podívejte se, jak je hashovací funkce implementována v Pythonu – konkrétně na implementaci SipHash. Zjistíte, že také neodpovídá vašim představám o hashovací funkci. A přitom to hashovací funkce je. Nějak nám to přibývá, co? Už dvě funkce, které celý svět uznává jako hashovací funkce, ale vašim pravidlům nevyhovují.

    Uživatel dw ničemu nerozumí, ale nedokáže to poznat, protože ničemu nerozumí. C.B.D.

  • 30. 7. 2021 23:13

    dw

    Precital ste si tu vetu celu?
    Ano, četl. Sice jste to přeložil, ale evidentně to stále nechápete. Vycházíte totiž ze svých mylných představ o tom, co je hashovací funkce a jak funguje JVM.

    Definicia hashovacej funkcie nie je zavisla na nejakej jave. Nie je zavisla od ziadnej konkretnej implementacie.

    RC patri do kategorie osobnych udajov ktore identifikuju osobu jednoznacne.
    Zjistěte si, co znamená slovo „jednoznačně“. Když mají dvě osoby stejné rodné číslo, nemůže rodné číslo identifikovat osoby jednoznačně.

    Tak hadam neskor narodeny obcania maju uz RC jedinecne (nepredpokladam ze software pre evidenciu obyvatelstva spachali nejake lopaty, i ked jeden nikdy nevie). Ti skor narodeny budu tiez figurovat v evidencii obyvatelstva, takze zrejme duplicity v RC, su v dnesnej dobe nerealne... Nejake duplicity sa realne mozu objavit az v roku 2054, do vtedy sa alezrejme najde nejake riesenie. I ked kolko ludi sa pri dnesnom zdravotnictve dozije 100 rokov?
    Preto zakon zrejme povazuje RC za jedinecne a ma pravdu.

    Evidentně jste začal tušit, že vám teče do bot, takže se z toho zkoušíte vykroutit. Bla bla bla... To řešení je prosté – nevíte, jak funguje JVM. A nevíte, co jsou hashovací funkce.

    K tomu aby som vedel ake poziadavky su kladene na hash funkcie nepotrebujem vediet ako funguje JVM. Tvrdenie ze neviem ako funguju hash funkcie v suvislosti s tym ze neviem do detailu ako funguje JVM, je argumentacny fail.

    Pro vaši informaci, Kotlin/JVM běží také nad JVM.

    Nemusi, hladajte kotlin native. Myslim ze nebude trvat dlho a v niektorej z buducich verzii sa uz dalvik neobjavi.

    Ale když si myslíte, že umíte Python, podívejte se, jak je hashovací funkce implementována v Pythonu – konkrétně na implementaci SipHash.

    Ktoru konkretnu vlastnost kladenu na hash funkciu SipHash nesplna?

    Uživatel dw ničemu nerozumí, ale nedokáže to poznat, protože ničemu nerozumí. C.B.D.

    Preco je obdobny vas nazor irelevantny som vam uz zdovodnil. Toto je len vas dalsi argumentacny fail - argumentum ad hominem. To ze som pouzil podobne tvrdenie na vas, ma svoj dovod: pricasto pouzivate Argumentum ad lapidem.

  • 31. 7. 2021 10:19

    Filip Jirsák

    Definicia hashovacej funkcie nie je zavisla na nejakej jave. Nie je zavisla od ziadnej konkretnej implementacie.
    Definice slouží k tomu, že vezmete nějaký objekt, porovnáte ho s definicí – a pokud definici naplňuje, víte, že ten objekt můžete nazývat tím jménem odpovídajícím definici. Takže vezmete Javovskou funkci Enum.hashCode(), zjistíte, že splňuje všechny požadavky na hashovací funkci, tudíž to je hashovací funkce.

    Ti skor narodeny budu tiez figurovat v evidencii obyvatelstva, takze zrejme duplicity v RC, su v dnesnej dobe nerealne...
    Jak už je dobrým zvykem, to, co vy považujete za nereálné, ve skutečnosti existuje. Ano, v evidenci obyvatel jsou duplicitní rodná čísla, protože se duplicitní rodná čísla šmahem neměnila všem, mění se jenom když o to dotyčný požádá.

    Preto zakon zrejme povazuje RC za jedinecne a ma pravdu.
    Opět se mýlíte. A to by stačilo si ten zákon přečíst. Ale i to je na vás moc složité a tak raději plácáte nesmysly. Zákon totiž explicitně vyjmenovává důvody pro změnu rodného čísla a mezi nimi výslovně uvádí duplicity.

    K tomu aby som vedel ake poziadavky su kladene na hash funkcie nepotrebujem vediet ako funguje JVM. Tvrdenie ze neviem ako funguju hash funkcie v suvislosti s tym ze neviem do detailu ako funguje JVM, je argumentacny fail.
    Opět polemizujete s něčím, co jsem nenapsal. Ve skutečnosti v tomto případě nevíte dvě věci – za prvé nevíte, jaké jsou požadavky na hashovací funkci. Takže o hashovacích funkcích v Javě nebo Pythonu, které splňují požadavky na hashovací funkci, tvrdíte, že to hashovací funkce není. Za druhé nevíte, jak funguje JVM, takže tvrdíte, že funkce Enum.hashCode() nesplňuje ani požadavky Java Collections API na funkci hashCode(), na kterém závisí implementace např. HashSet a HashMap.

    Nemusi, hladajte kotlin native.
    Nevystupoval vy jste tu dříve pod přezdívkou „j“? To byl také expert, který ať napsal co napsal, bylo to vždy špatně. Kotlin má tři varianty: Kotlin/JVM (nejstarší), Kotlin/Native a Kotlin/JS. Já schválně napíšu Kotlin/JVM, aby každý prvok pochopil, o čem přesně je řeč. Ale vám to stejně nedojde.

    Ktoru konkretnu vlastnost kladenu na hash funkciu SipHash nesplna?
    Vlastnosti kladené všemi ostatními na hash funkce splňuje všechny. Nesplňuje ovšem vaši pomýlenou představu o determinitě, protože se chová podobně, jako javovské hashCode – pro objekt reprezentující stejnou entitu při různých bězích vrací různé hodnoty.

    Preco je obdobny vas nazor irelevantny som vam uz zdovodnil.
    Cha cha. V každém vašem komentáři rozšíříte okruh nesmyslů, které jste napsal. Nevyvrátil jste jedinou věc, kterou jsem napsal já. Důvod, proč si stále myslíte, že máte pravdu, je jediný – odmítáte si informace ověřovat. Stejné to bude i s tímhle komentářem. Napsal jsem, co je v zákoně o rodných číslech. Vy si ten zákon ale nepřečtete a budete dál trvat na svém. I kdybych vám dal odkaz na zákon a konkrétní paragraf, stejně si to nepřečtete. I kdybych vám dal prolink, na který stačí kliknout, aby se vám ten konkrétní paragraf zobrazil, stejně si to nepřečtete a budete trvat na svém. To není žádný diskusní faul ad hominem, protože s vámi není žádná diskuse, protože vy nejste diskuse schopen. Vy prostě jakékoli argumenty ignorujete. Což opět uvidíme na dalším vašem komentáři, ke nebude žádná omluva, že jste si to nastudoval a mýlil jste se jak s neměnností rodných čísel tak s jejich unikátností. Nebude tam žádná omluva, že jste se mýlil a Kotlin/JVM je něco jiného, než Kotlin/Native. Budou ta, zase jen další vaše výmluvy a nesmysly.

  • 31. 7. 2021 22:41

    dw

    Definice slouží k tomu, že vezmete nějaký objekt, porovnáte ho s definicí – a pokud definici naplňuje, víte, že ten objekt můžete nazývat tím jménem odpovídajícím definici. Takže vezmete Javovskou funkci Enum.hashCode(), zjistíte, že splňuje všechny požadavky na hashovací funkci, tudíž to je hashovací funkce.

    Takze podla vas ak referencia splna vacsinu vlastnosti hashu tak referencia je hash? Tento argumentacny klam je unahlene zobecnenie. Rovnako mozete tvrdit ze ak uhorka splna vlastnosti dilda, tak uhorka je dildo. Nie, stale je to uhorka.

    Ti skor narodeny budu tiez figurovat v evidencii obyvatelstva, takze zrejme duplicity v RC, su v dnesnej dobe nerealne...
    Jak už je dobrým zvykem, to, co vy považujete za nereálné, ve skutečnosti existuje. Ano, v evidenci obyvatel jsou duplicitní rodná čísla, protože se duplicitní rodná čísla šmahem neměnila všem, mění se jenom když o to dotyčný požádá.

    Aka je pravdepodobnost takehoto vyskytu? Vadia niecomu tieto extremne male odchylky? Pre ulozenie v db staci dostatocne dobra dekompozicia, ktora vyriesi aj problem ze osoba moze mat viacero RC (zmena pohlavia, cuzdinec a podobne). Formalne je to jednoznacny identifikator. Alebo inak, kolko krat sa vam stalo ze pri importe do db nastal konflikt primarneho kluca? Vylucuje to preto primarny kluc ako jednoznacny identifikator? Vasu odpoved by som klasifikoval ako statisticky sylogismus.

    Preto zakon zrejme povazuje RC za jedinecne a ma pravdu.
    Opět se mýlíte. A to by stačilo si ten zákon přečíst. Ale i to je na vás moc složité a tak raději plácáte nesmysly. Zákon totiž explicitně vyjmenovává důvody pro změnu rodného čísla a mezi nimi výslovně uvádí duplicity.

    Zakon 133/2000 Hlava III § 13 odstavec 1 a odstavec 6. Znova mi odporucate prestudovat si nieco co sam neovladate.

    K tomu aby som vedel ake poziadavky su kladene na hash funkcie nepotrebujem vediet ako funguje JVM. Tvrdenie ze neviem ako funguju hash funkcie v suvislosti s tym ze neviem do detailu ako funguje JVM, je argumentacny fail.
    Opět polemizujete s něčím, co jsem nenapsal. Ve skutečnosti v tomto případě nevíte dvě věci – za prvé nevíte, jaké jsou požadavky na hashovací funkci. Takže o hashovacích funkcích v Javě nebo Pythonu, které splňují požadavky na hashovací funkci, tvrdíte, že to hashovací funkce není. Za druhé nevíte, jak funguje JVM, takže tvrdíte, že funkce Enum.hashCode() nesplňuje ani požadavky Java Collections API na funkci hashCode(), na kterém závisí implementace např. HashSet a HashMap.

    Uz som vam dokazal ze tuto problematiku mam na rozdiel od vas nastudovanu dobre. Vy tu dokazujete ze Enum.hashCode vracia hash. Pritom tato funkcia vracia referenciu ktoru dostane na vstupe. Funkcia fn(a)==a nie je hash funkciou ai omylom.

    Nemusi, hladajte kotlin native.
    Nevystupoval vy jste tu dříve pod přezdívkou „j“? To byl také expert, který ať napsal co napsal, bylo to vždy špatně. Kotlin má tři varianty: Kotlin/JVM (nejstarší), Kotlin/Native a Kotlin/JS. Já schválně napíšu Kotlin/JVM, aby každý prvok pochopil, o čem přesně je řeč. Ale vám to stejně nedojde.

    dw: Google v androide nahradilo javu kotlinom, fj: kotlinbezi nad jvm, dw: nemusi, hladajte kotlin native, fj: viz kurziva vyssie... Ak v tom mate taky ozaj uzastny prehlad, tak by ste mohol vediet ze 1) na androide bezia aj native aplikacie 2) jvm v skutocnosti v androide nie je, ale ART kompiluje jvm bytecode aplikacie.

    Ktoru konkretnu vlastnost kladenu na hash funkciu SipHash nesplna?
    Vlastnosti kladené všemi ostatními na hash funkce splňuje všechny. Nesplňuje ovšem vaši pomýlenou představu o determinitě, protože se chová podobně, jako javovské hashCode – pro objekt reprezentující stejnou entitu při různých bězích vrací různé hodnoty.

    Tuto vlastnost moze mat ktorakolvek hash funkcia, staci data pred pouzitim hash funkcie posolit, sol moze byt odvodena od pid. Ak v ramci jedneho procesu ulozite objekt o cache, dealokujete ho a po case ho vyberiete z cache tak ani omylom nebude mat rovnaku referenciu. Preto je hashCode nedeterministicke, nie pre to ze obsahuje zdanlivo nahodny prvok. Btv, zase prekrucate to co som napisal, na to som obzvlast haklivy, zacinamsi to brat dost osobne.

    posledny odstavec - nebudem linkovat, kto che si dristy precita

    Ste zbytocny trol, ktory si mysli ze svoje nedostatky vo vedomostiach obkeca. To mozete skusat trebars na studentky. A zacima mat obavu ze s vasim programovanim je to podobne. Nejako tu spatlaninu obkecame, ved zakaznik tomu nerozumie... Az sa najde niekto kto tomu rozumie.

    31. 7. 2021, 22:43 editováno autorem komentáře

  • 31. 7. 2021 22:54

    Filip Jirsák

    Pokud něco splňuje všechny požadavky na hashovací funkci, je to hashovací funkce. Fakt by mne zajímalo, co byste říkal na to, že vám zdravotní pojišťovna nic nezaplatí nebo nebudete dostávat důchod, protože máte duplicitní rodné číslo, takže bohužel nemůžete být v jejich databázi. Zákon jste našel správný, teď ještě tam najít § 17. Zkuste se pořádně soustředit a porovnat texty „Kotlin/JVM“ a „Kotlin“. I při vaší inteligenci byste mohl narazit na jistý rozdíl. Zejména když to bude už třetí váš pokus. Končím s vámi, takového blba jako jste vy jsem tu ještě nepotkal. Osobně si to berte.

  • 31. 7. 2021 23:08

    dw

    Funkcia function hash(reference){ return reference } nie je hash funkcia i ked je tak pomenovana.

    § 17 vymedzuje postup tak aby bol § 13, odstavec 6 splneny. Ten znie: Totéž rodné číslo nesmí být přiděleno více fyzickým osobám. Zeby obratena kauzalita.

    Co trebars C a C/i386. Vy myslite ze v zdrojakoch pre platformu jvm a native bude nejaky podstatny rozdiel?

    Blb ste sam, obkecavat to mozete kolko chcete. Este som nestretol cloveka ktory by nedokazal napisat suvislejsi text bez argumentacneho failu, i ked na to bol mnohonasobne upozorneny...

    31. 7. 2021, 23:09 editováno autorem komentáře