SQL ServerのHashBytes varbinaryからBigintへの変換

Question

値のセットのハッシュを生成するときに、結果をHashBytesからbigintに変換する方法を示すブログがいくつか見られます。これはデータウェアハウスでは本当に一般的です。これは、結合に適しており、良好なパーティション分配を提供する整数としてハッシュを格納する利点を有する。

これは良い練習である場合でも、私は思っています。 HashBytesでSha1を使用すると、16バイトの結果が生成されます。 bigintは8バイトのデータ型なので、これをbigintに変換する前に16バイトを切り捨てる必要はありませんか？もしそうなら、これは衝突の可能性を高めるように思われる。

varbinaryハッシュをかなり長い間bigintに変換していますが、まだ衝突が発生していませんが、上記の前提が真実であれば間違いなく愚かなようです。

これをテストするには、bigintから元のハッシュに戻すことができるかどうかを確認するためにいくつかのハッシュを変換しようとしましたが、問題を示している可能性があります（または、 ）。

あなたの数学者はこれについて考えていますか？ ありがとうございます！彼らは古いハッシュアルゴリズムを廃止しようとしていることをSQL 2016の最近の兆候で

DECLARE @value varchar(5) = '12345' 
DECLARE @hash varbinary(max) = hashbytes('SHA1', @Value) 

SELECT @hash AS OriginalHash 
SELECT CAST(@hash as nvarchar(max)) AS StringHash 
SELECT CAST(CAST(@hash as nvarchar(max)) as varbinary(max)) AS StringBackToOriginalHash 
SELECT CAST(@hash as bigint) AS BigIntHash 
SELECT CAST(CAST(@hash as bigint) as varbinary(max)) AS BigIntBackToOriginalHash 

、我々はかなり多くのスペースを取るだろう長いハッシュあるSha2_256とSha2_512を使用せてしまいます。これは、古いSha1ハッシュと衝突耐性であれば、bigintの使用が素晴らしい理由もあります。

Answer 1

実際、私はこの記事の答えを見つけた可能性があります。あなたはSSN値の何百万人で作業している場合は、ハッシュ衝突の許容できないリスクを作成することが切り捨てられたハッシュから構築されたbigint型を使用して https://blogs.msdn.microsoft.com/sqlcat/2005/09/16/using-hashing-to-obscure-sensitive-data/

2）。ハッシュ衝突の可能性は、2 ^（＃ビット/ 2）入力値が与えられたときに衝突の確率が50％であるという推定値を用いて計算することができる。 7バイトを使用して計算されたbigintの場合、2^28の異なる値 - つまり2億6,800万の異なるSSNをハッシュすると、衝突の確率は50％です。したがって、入力値の世界が大きい場合は、完全なハッシュ・ストリングを使用するか、ハッシュのより長いサブストリングを10進値に変換することができます。