Czy można obciąć skrót SHA256 na 128 bitów?

Hasły MD5 i SHA-1 mają słabe punkty przed atakami kolizyjnymi. SHA256 nie wypuszcza jednak 256 bitów. Czy mogę bezpiecznie wziąć pierwsze lub ostatnie 128 bitów i użyć tego jako skrótu? Wiem, że będzie słabszy (ponieważ ma mniej bitów), ale czy będzie działać?Czy można obciąć skrót SHA256 na 128 bitów?

Zasadniczo chcę użyć tego do unikalnej identyfikacji plików w systemie plików, które mogą pewnego dnia zawierać tryliony plików. Jestem świadomy problemu z urodzinami, a 128-bitowy hasz powinien dać około 1 biliona szans na tryliona plików, w których znajdowałyby się dwa różne pliki o tym samym haszu. Mogę żyć z tymi szansami.

Z czego nie mogę żyć, to jeśli ktoś może z łatwością, celowo włożyć nowy plik o tym samym haśle i tych samych początkowych znakach pliku. Wierzę w MD5 i SHA1, to jest możliwe.

Źródło

2010-06-11 Sunny Hirai

Myślałem, że paradoks urodzin daje niższe kursy niż to, ale Wikipedia zgadza się z tobą: http: //en.wikipedia.org/wiki/Birthday_paradox # Probability_table –

Powiązane pytanie: http://stackoverflow.com/questions/2256423/truncating-an-md5-hash-how-do-i-calculate-todd---colollision-occuring – Shadok

Zobacz też: http://security.stackexchange.com/questions/18385/does-truncating-the-cryptographic-hash-make-it-impossible-to-crack – Luc

Tak, to zadziała.

Dla przypomnienia, znane są ataki kolizyjne na MD5, ale ataki SHA-1 są w tym momencie całkowicie teoretyczne (nigdy nie znaleziono kolizji SHA-1 ... jeszcze).

Źródło

2010-06-11 22:58:37

SHA-256 (skrót, o którym mówi OP) to SHA-2, a nie SHA-1 - tak myślę? I jak dotąd nie znaleziono kolizji dla SHA-2 ... nawet teoretycznie. – user353297

@ blueraja- nie do końca prawdziwa. sprawdź: http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf –

@ mrl33t: Nie; SHA-1 ma teoretyczne luki w zabezpieczeniach, ale SHA-256 (który jest częścią pakietu SHA-2) nawet go nie ma. Biorąc pod uwagę rozmiar skrótów SHA-256 jest 2 razy 128 razy WIĘKSZY niż SHA-1, a SHA-2 jest uważany za bardziej teoretycznie bezpieczny, nie jest prawdopodobne, że w najbliższym czasie dojdzie do kolizji SHA-256. –

Ale czy warto? Jeśli masz hash dla każdego pliku, to zasadniczo masz narzut dla każdego pliku. Powiedzmy, że każdy plik musi zajmować co najmniej 512 bajtów (typowy sektor dyskowy) i że przechowujesz te skróty na tyle kompaktowo, aby nie każdy skrót mieszający zajmował znacznie więcej niż rozmiar skrótu.

Tak więc, nawet jeśli wszystkie twoje pliki mają 512 bajtów, najmniejsze to: 16/512 = 3.1% lub 32/512 = 6.3%. W rzeczywistości, założyłbym się, że twój średni rozmiar pliku jest wyższy (chyba że wszystkie twoje pliki to 1 sektor ...), więc narzut byłby mniejszy.

Teraz ilość miejsca potrzebna do skrótów skaluje się liniowo wraz z liczbą posiadanych plików. Czy to dodatkowe miejsce warte , że dużo? Nawet jeśli miałeś wspomniane trylionowe pliki - to jest 1 000 000 000 000 * 16 = ~29 TiB, czyli dużo miejsca, ale pamiętaj: twoje dane to 1 000 000 000 000 * 512 = 465 TiB. Liczby są bezwartościowe, naprawdę, ponieważ nadal są napowietrzne. Ale na tym poziomie, gdzie masz pół petabajta pamięci, czy 15 terabajtów ma znaczenie? Czy na każdym poziomie oszczędności wynoszą jakieś 100%? I pamiętaj, że jeśli są większe, oszczędzasz mniej. (Które, prawdopodobnie, są to: powodzenia uzyskanie rozmiaru sektora o wielkości 512 bajtów przy tym rozmiarze dysku twardego.)

Czy to jest ta 3% lub mniej oszczędności na dysku warte potencjalnego ryzyka w zakresie bezpieczeństwa. (Które pozostawiam bez odpowiedzi, ponieważ nie jest to moja filiżanka herbaty).

Czy można, na przykład, zgrupować pliki w logiczny sposób, aby mieć mniej plików? (Mam na myśli, jeśli masz tryliony 512-bajtowych plików, czy naprawdę chcesz mieszać każdy bajt na dysku?)

Źródło

2010-06-11 23:21:54 Thanatos

Nie odpowiada na pytanie. Czy to? – ALOToverflow

@ALOToverflow: Nie, nie działa. Ale to nie znaczy, że nie ma to znaczenia: czasami kwestionowanie przesłanki pytania może prowadzić do lepszego rozwiązania zarówno dla plakatu, ogólnej publiczności czytającego pytanie później przez Google, jak i dla obu: SO jest tutaj pomocne. więc uważam takie posty za warte. Być może powinienem był mocniej podkreślić aspekt bezpieczeństwa: z mojego doświadczenia wynika, że w większości rzeczy związanych z kryptografią, jeśli zboczysz z utartej ścieżki, zdarzają się dziwne (i zazwyczaj złe) rzeczy. Czy to jest warte niewielkich oszczędności na dysku? (Być może, ale to zależy od przypadku użycia). – Thanatos

Tak, to zadziała. Teoretycznie lepiej jest XOR dwie połówki razem, ale nawet obcięty SHA256 jest silniejszy niż MD5. Wciąż powinieneś rozważyć wynik zamiast 128-bitowego hasza zamiast 256-bitowego hasha.

Moja szczególna rekomendacja w tym konkretnym przypadku polega na przechowywaniu i odwoływaniu się przy użyciu wyjątku HASH +, gdzie unikalność jest liczbą różnych plików widocznych dla tego skrótu. W ten sposób nie upadasz całkowicie, jeśli ktoś będzie próbował przechowywać przyszłe odkryte wektory kolizji dla SHA256.

Źródło

2010-06-11 23:24:53 Joshua

+10

Nie mogę znaleźć żadnego odniesienia, które mówi, że teoretycznie lepiej jest XOR razem połówki, i jestem sceptyczny, że tak jest. Ciekawy pomysł z uniquifier. –

GregS: niektóre z wczesnych ataków na MD5 spowodowały kolizje na większości wartości mieszania z jedną lub dwiema komórkami. – Joshua

@Joshua To brzmi jak jego empiryczne (nie teoretycznie) lepsze. Interesuje mnie również odniesienie do tego, dlaczego XOR byłby lepszy. – Drux

Czy można obciąć skrót SHA256 na 128 bitów?

Odpowiedz

Powiązane problemy