アカウント名:
パスワード:
携帯電話からの接続なんて携帯事業者のサーバーが間にプロキシみたいに入ってるんだし、送信するのを「契約者ＩＤ」じゃなくて「契約者ＩＤと送信先ドメインを足した値のハッシュ」にすればいいのに、と思うんだけど、面倒だからやらないのかしらね。もちろんハッシュ値が全ユーザーの間で一意になるような仕掛けは必要だから、インフラ側の構築はちょっと工夫が必要にはなりそうだけど。 これなら特定のドメインにアクセスした時の契約者ＩＤが他ドメインに漏洩したところで困らないし、特定ドメインの範疇であればユーザーとの紐付けは従来通り可能だからコンテンツビジネスにも殆ど影響を及ぼさないはず。少なくともユーザー情報をこっそり売り飛ばすところまで「ビジネス」としているようなところ以外は。
ハッシュはアルゴリズムによっては衝突することがありますよ。逆に、「一意でない値を何らかの方法でハッシュにかけたら必ず一意でなくなる」ことが保証されている場合、そのハッシュ関数は可逆性があることになるので親トピのような用途には不向きです。
固定長のハッシュは有限個のハッシュ値（2^ハッシュ長）しかもてないのに対し、ハッシュをかけるべきデータは理論上無限なのですからハッシュの衝突はどのようなアルゴリズムを用いても避けられないでしょう。# 固定長じゃないものをハッシュって言うんですかね?
送信先はIPアドレス空間全部より広い可能性はありますよ。ネームベースのバーチャルサーバはあるし、サーバ単位で送信先のドメインを切っていいとは限らない（rakuten.co.jp内に無数のショップがあるように）。
はっ！
無限の情報量をもつデータを固定長のハッシュ値に対応させることができるということは…無限の圧縮率の情報圧縮も可能っ！！ってことか！
さっそく特許申請の準備だっ！えーとまず退職願を書いて…
|メッセージ|=|ハッシュ|でない限り必ず衝突は存在するのでは？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
対案というか…… (スコア:2)
携帯電話からの接続なんて携帯事業者のサーバーが間にプロキシみたいに入ってるんだし、送信するのを「契約者ＩＤ」じゃなくて「契約者ＩＤと送信先ドメインを足した値のハッシュ」にすればいいのに、と思うんだけど、面倒だからやらないのかしらね。もちろんハッシュ値が全ユーザーの間で一意になるような仕掛けは必要だから、インフラ側の構築はちょっと工夫が必要にはなりそうだけど。
これなら特定のドメインにアクセスした時の契約者ＩＤが他ドメインに漏洩したところで困らないし、特定ドメインの範疇であればユーザーとの紐付けは従来通り可能だからコンテンツビジネスにも殆ど影響を及ぼさないはず。少なくともユーザー情報をこっそり売り飛ばすところまで「ビジネス」としているようなところ以外は。
Re:対案というか…… (スコア:0)
そんなのいらないよ。ハッシュすれば一意。
Re: (スコア:0)
ハッシュはアルゴリズムによっては衝突することがありますよ。
逆に、「一意でない値を何らかの方法でハッシュにかけたら必ず一意でなくなる」ことが保証されている場合、そのハッシュ関数は可逆性があることになるので親トピのような用途には不向きです。
Re: (スコア:0)
いいえ。暗号学的ハッシュ関数は、衝突しません。
（まさかハッシュテーブル用のハッシュ関数を使うわけがないですよね。）
Re: (スコア:0)
固定長のハッシュは有限個のハッシュ値（2^ハッシュ長）しかもてないのに対し、ハッシュをかけるべきデータは理論上無限なのですからハッシュの衝突はどのようなアルゴリズムを用いても避けられないでしょう。
# 固定長じゃないものをハッシュって言うんですかね?
Re: (スコア:0)
Re: (スコア:0)
送信先はIPアドレス空間全部より広い可能性はありますよ。
ネームベースのバーチャルサーバはあるし、サーバ単位で送信先のドメインを切っていいとは限らない（rakuten.co.jp内に無数のショップがあるように）。
ハノイの塔 (スコア:0)
はっ！
無限の情報量をもつデータを固定長のハッシュ値に対応させることができるということは…
無限の圧縮率の情報圧縮も可能っ！！ってことか！
さっそく特許申請の準備だっ！えーとまず退職願を書いて…
Re: (スコア:0)
|メッセージ|=|ハッシュ|でない限り必ず衝突は存在するのでは？