peceed

@Jarek To jest raczej oczywiste, że wynikowy algorytm haszujący będzie miał koszty pomięciowe i czasowe praktycznie równe sumie kosztów swoich składowych ( w praktyce można zamortyzować koszty I/O). Zapostulowałem, że złożenie dwóch rozsądnych funkcji mieszających operacją xor nie może dać w efekcie funkcji _słabszej_ od każdej składowej. Można oczywiście łatwo celowo skonstruować taki przypadek celowo - 2 identyczne funkcje. Intuicja podpowiada jednak, że w przypadku zastosownia wystarczająco różnych i bezpiecznych składowych wynikowa funkcja jest znacznie trudniejsza do złamania niż składowe. Jest masa rozmaitych zastosowań w których ważniejsze jest bezpieczeństwo od wydajności. Zastosowanie (i ustandaryzowanie) podwójnego haszowania dwoma algorytmami mogłoby być znacznie lepszą praktyką niż proste zwiększanie długości klucza.

Zastanawia mnie dlaczego nie rozpatruje się skrótów typu sha2^sha3. Przy zupełnie nieskorelowanych funkcjach haszujących efektywna trudność złamania w prosty sposób powinna się zbliżać do przeglądu wszystkich możliwych rozwiązań, i nawet możliwość skutecznego ataku na każdą składową nie daje najmniejszej możliwości ataku na funkcję złożoną. W ten sposób sha2-256 ^ sha3-256 ze wszelkich praktycznych względów mogłoby być równie bezpieczne jak sha2-512, miałby taki sam koszt obliczniowy a dawało mniejszy skrót. Mało tego - można by przyjąć zasadę, że funkcję skrótu zawsze tworzymy przez połączenie dwóch niezależnych i mocnych algorytmów, i przy pojawieniu się skutecznego ataku na jedno ogniwo - możemy bez paniki je wymienić. Co do braku zainteresowania ASL - jak w życiu, wiele rzeczy najlepiej zrobić samemu. Konkurs na SHA-4 powinien wystartować w ciągu następnej dekady