Java の serialVersionUID (long または 64 ビット) を自動的に生成したいと考えています。シリアル化されるオブジェクトを区別するものは、約 20 の整数によって決定されますが、必ずしも 20 の整数ではありません。整数をコンマ区切りの数値文字列に変換し、SHA-256 ハッシュ関数で実行するつもりです。
SHA-256 は 32 バイト (256 ビット) の長さで、serialVersionUID (64 ビット) に収まるようにする必要があるため、それを 64 ビット値に変換し、適切なハッシュの特性の損失を最小限に抑えるにはどうすればよいでしょうか?
余分なビットを切り取るだけです。物事を複雑にする必要はありません。最初の (またはその他の) 64 ビットを取得するよりも優れた方法がある場合、そもそもハッシュが壊れています。
まず第一に、通常の意味で適切なハッシュを圧縮できる可能性は低いです。圧縮とは、冗長性を減らすリバーシブル エンコーディングに関するものです。適切なハッシュでは、削減する冗長性がないため、圧縮は効果がありません。
SHA-256 は 32 バイト (256 ビット) の長さで、serialVersionUID (64 ビット) に収まるようにする必要があるため、それを 64 ビット値に変換し、適切なハッシュの特性の損失を最小限に抑えるにはどうすればよいでしょうか?
では、それらの優れた特性は何ですか？良いハッシュの主な特徴は、それを元に戻すことが実際的ではないということです。つまり、ハッシュの結果となる可能性のある入力を計算することは実際的ではありません。また、関連する特性として、特定のハッシュを生成する既知の入力が与えられた場合、同じハッシュを生成する別の入力 (衝突) を生成することは実際的ではありません。
256 ビットから 64 ビットのハッシュに移行すると、ハッシュを元に戻したり、ハッシュの衝突を生成したりすることが非常に簡単になります。基本的に、64 ビット ハッシュとは2^64、任意のランダムな入力が特定のハッシュを持つ可能性が 1 つあることを意味します。その確率は、十分なコアを持つ一部の「悪者」が（妥当な時間内に）成功する可能性が十分に高く、ブルートフォースを妥当なオプションにするのに十分な大きさです。
しかし、それは本当に重要ですか？衝突するserialVersion文字列を作成することで、誰かが何を達成しますか? これらの文字列は秘密ではなく、オブジェクトの API について決定的なことは何も教えてくれません...
要するに、serialVersion 文字列が使用されるように設計されているため、これらの削減されたハッシュが使用されている場合、(たとえば) SHA-256 ハッシュの最初の 64 ビットのみを使用しても問題はありません。XOR やチェックサムを実行したり、その他の複雑な変換を行う必要はありません。
SHA-256 ダイジェストの巡回冗長検査 (CRC) を計算できます。
64ビットのチェックサムを使用するか、SHAに固執したい場合は、64ビットのチャンクをXORします。