Во-первых, маловероятно, что вы сможете сжать хороший хеш в обычном смысле. Сжатие — это обратимое кодирование, уменьшающее избыточность. В хорошем хеше не должно быть избыточности, которую нужно уменьшить, и, следовательно, сжатие будет неэффективным.
Поскольку SHA-256 имеет длину 32 байта (256 бит), и мне нужно, чтобы он вписывался в serialVersionUID (64 бита), как я могу преобразовать его в 64-битное значение и свести к минимуму потерю характеристик хорошего хэша?
Так что же это за хорошие характеристики? Что ж, основная характеристика хорошего хэша заключается в том, что его нецелесообразно реверсировать; то есть нецелесообразно обрабатывать возможный ввод, который привел к хешу. И связанная с этим характеристика заключается в том, что при известном вводе, который создает данный хэш, нецелесообразно создавать другой ввод (т.е. коллизию), который дает тот же хэш.
Теперь, когда вы переходите с 256-битного хэша на 64-битный, вы намного проще переворачивать хэш или создавать коллизию для хэша... методом грубой силы. По сути, 64-битный хэш означает, что в 2^64 есть один шанс, что любой случайный ввод будет иметь заданный хэш. Эта вероятность достаточно велика, чтобы какой-нибудь «плохой парень» с достаточным количеством ядер имел достаточно хорошие шансы на успех (в разумное время), чтобы сделать грубую силу разумным вариантом.
Но действительно ли это имеет значение? Чего можно добиться, создав конфликтующую строку serialVersion? Эти строки не являются секретными и ничего определенного не говорят об API объекта...
Суть в том, что если эти сокращенные хэши используются, поскольку строки serialVersion предназначены для использования, то не будет никаких проблем (например) только с использованием первых 64 бит хэша SHA-256. Нет необходимости в XOR, контрольной сумме или каких-либо других более сложных преобразованиях.
person
Stephen C
schedule
19.10.2012
