Polskie znaki diakrytyczne (ą, ć, ę, ł, ń, ó, ś, ź, ż) można zakodować w Unicode na dwa sposoby: jako pojedynczy, gotowy znak (NFC) albo jako literę bazową plus osobny znak łączący (NFD). Ten sam napis "łódź" utworzony na różnych systemach czy w różnych aplikacjach może więc składać się z zupełnie innych bajtów, mimo identycznego wyglądu na ekranie — a to oznacza dwa różne hashe dla „tego samego” tekstu.
Dlaczego to zaskakuje przy haszowaniu polskiego tekstu
Sam algorytm skrótu działa bezbłędnie — po prostu widzi różne bajty i generuje różne wyniki. Prawdziwy problem leży o poziom wyżej: przy porównywaniu lub haszowaniu polskiego tekstu pochodzącego z różnych źródeł (skopiowanego ze strony, z aplikacji, z pliku Word) warto najpierw znormalizować go do jednej postaci Unicode, inaczej wizualnie identyczne teksty zostaną błędnie uznane za różne.
Dlaczego MD5 i SHA-1 uważa się za niebezpieczne
Dla obu algorytmów znaleziono praktyczne sposoby na stworzenie dwóch różnych zestawów danych z tym samym skrótem — tzw. kolizję. To czyni je nieodpowiednimi tam, gdzie liczy się siła kryptograficzna, choć nadal są używane tam, gdzie potrzebna jest tylko szybka weryfikacja integralności.
SHA-256 i rodzina SHA-2
SHA-256 generuje 256-bitowy skrót i jak dotąd nie ma znanych praktycznych kolizji. Jest używany w blockchainach, certyfikatach TLS i weryfikacji integralności oprogramowania.
Do czego to się przydaje
- Sprawdzanie integralności pobranych plików przez porównanie z opublikowanym skrótem.
- Zrozumienie, dlaczego ten sam polski tekst z dwóch różnych źródeł może dać dwa różne skróty.
- Tworzenie krótkich, unikalnych odcisków dla dużych ilości danych.
Dlaczego SHA-3 nie zastąpił SHA-2
SHA-3 wybrano jako zwycięzcę osobnego konkursu NIST na wypadek, gdyby w SHA-2 kiedyś znaleziono fundamentalną podatność — to „polisa ubezpieczeniowa" oparta na zasadniczo innej konstrukcji wewnętrznej (Keccak). Ponieważ praktycznych ataków na SHA-2 wciąż nie znaleziono, SHA-256 pozostaje domyślnym standardem w większości systemów.