SHA512 Liczenie skrótu od skrótu

Właśnie skończyłem opracowywanie JSONA udostępnionego przez MF do weryfikacji, czy kontrahent jest czynnym platnikiem VAT i czy konto na które przelewamy zaplatę jest przez niego zgłoszone do KAS. Nie jest to podane wprost tylko w postaci hashy SHA512, wyliczanego ze stringa złożonego z daty+nip+konto.

Opis, aby wprowadzić kontekst. Po tym jak 3 krotnie nie znalazłem wyliczonego hasha, doczytałem, że trzeba to zrobić 5000 razy, w pseudo kodzie

toHash="datanipkonto"
for (int i = 0; i < 5000; i++) {
   toHash = sha512(toHash)
}
search(toHash)

Jako, że krytpografią/bezpieczeństwem się nie zajmuje, ale jaki jest sens takiego rozwiązania?

Moim zdaniem nie wpływa to na bezpieczeństwo, sklaniam się raczej ku teorii, że chodzi o to by utrudnić zgadywanie konta na podstawie hashy.

To tylko moje domysły, dlatego luźno przy piątku pytam mądrzejszych ode mnie co o tym myślą.

Chodzi o to żeby wyliczenie hasha było kosztowne i ew. przeszukiwanie słownikowe było utrudnione.

https://crypto.stackexchange.com/a/21055

Panczo napisał(a):

Jako, że krytpografią/bezpieczeństwem się nie zajmuje, ale jaki jest sens takiego rozwiązania?

Najbezpieczniejsze rozwiązanie jest jeszcze lepsze: wygenerowanie losowego ciągu (soli), uruchomienie iterowanej ileś tysięcy razy funkcji hash na tym losowym ciągu sklejonym z wejściowym tekstem i zwrócenie ciągu sól + wynik tej funkcji. Sól chroni przed tęczowymi tablicami, pozwalającymi użyć więcej pamięci, ale mniej czasu, a wysoka liczba iteracji spowalnia próbowanie wszystkich możliwości.

Przy wszelkiego rodzaju podpisywaniu komunikatów dodatkowo pojawia się length extension attack, tzn. znając sha512(x) i y można wyliczyć sha512(x + y), pomimo braku znajomości x, bo wynik sha512 na krótkim ciągu jest jednym ze stanów, w jakim znajduje się algorytm uruchomiony na długim ciągu, wystarcza do wznowienia liczenia. W takich sytuacjach jest potrzebny HMAC albo ucięty hash np. SHA512/256, gdzie wynik na prefiksie nie wystarcza do wznowienia liczenia na całości, bo brakuje drugiej połowy stanu. Przy SHA3 też wcale nie ma takiego problemu, bo cały stan algorytmu w trakcie liczenia to więcej niż tylko bieżący wynik.

Moim zdaniem nie wpływa to na bezpieczeństwo

Teoretycznie trochę wpływa, bo jeśli SHA-512 ma konflikt wśród 512 bitowych stringów, to zmniejszamy przeciwdziedzinę.

sklaniam się raczej ku teorii, że chodzi o to by utrudnić zgadywanie konta na podstawie hashy.

Zapewne jest to powód. Ogólnie to podobna funkcja jest znana jako PBKDF2, ale tam mamy 2 argumenty.

wygenerowanie losowego ciągu (soli), uruchomienie iterowanej ileś tysięcy razy funkcji hash na tym losowym ciągu sklejonym z wejściowym tekstem i zwrócenie ciągu sól + wynik tej funkcji

Nie jest to najbezpieczniejsze rozwiązanie, bo PBKDF2 nie jest uważane za najlepsze możliwe podejście. Dodatkowo to co piszesz nawet tym nie jest, bo składa się z trochę bardziej rozbudowanego algorytmu.

Przy SHA3 też wcale nie ma takiego problemu, bo cały stan algorytmu w trakcie liczenia to więcej niż tylko bieżący wynik.

SHA3 ma inny problem, bo jeśli wymusimy na użytkowniku użycie funkcji SHAKEx i zwrócimy m bitów to mamy wszystkie n bitowe hashe dla n < m, przez co jeśli chcemy być bezpieczni przeciwko takim atakom, to musimy opracować odpowiedni algorytm by zmienić hash w zależności od wymaganej długości skrótu.

Opisany schemat to https://en.wikipedia.org/wiki/Key_stretching
Solenie haseł jest niezależną techniką. Można je stosować razem i często się tak robi (np my tak robimy w firmie).
Ja tworzę aplikację w banku, która ma hasła zaszyfrowane zahashowane bcryptem. Zespół od bezpieczeństwa kazał nam ustawić liczbę iteracji hashowania na co najmniej 10 tysięcy razy (bcrypt ma zmienną ilość iteracji, w zależności od woli użytkownika).

@hauleth: o tym bezpieczeństwie to był skrót myślowy, bo o ile może to być problematyczne szukanie numeru konta na podstawie JSONa. To o jakbym rzeczywiście potrzebował takich danych to pobrałbym to bezpośrednio z API. Obejście tego limitu zapytań nie jest szczególnie trudne. Więc w tym kontekście to jest para w gwizdek, bo te dane są dostępne wprost.