- ベストアンサー
なぜハッシュ関数はユーザーに直接活用されないのか？
- ハッシュ関数はユーザーに直接活用されないのはなぜでしょうか？
- ハッシュ関数を活用する方法はあるのか？
- ハッシュ関数の活用が進まない理由は何か？
- kasoupctte
- お礼率85% (36/42)
- ネットワーク
- 回答数4
- ありがとう数6
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
「良さそうなアイディアのものもあれば意図不明のものもある」という感想です。 (1) 種パスワードを一つにし、手元のパスワードが単一でも複数のパスワードを利用できる アリですね。 っていうか公開鍵暗号ってそんな感じのことやってますよね。 主要な処理はハッシュでないとは言え、公開鍵暗号は事実上一方向の関数を使って互いを認証します。 その秘密鍵を利用できる人を判別するため、秘密鍵にはパスフレーズをかけます。 全体としての仕組みはともかくとして、ユーザに見える「単一のパスワードを入れれば全部解決」という部分は、ご提案とあんまり変わらないですよね。実運用もされて現在のところ安全ですし、ビット数や関数を変えればすぐにより安全な運用に移行できます。 あとは、シングルサインオンとかOpenIDとかの認証系も、ハッシュではないとは言え目的は似ています。 (2) URLのところにハッシュ値を入れれば即対応する内容が表示される hash値でリソースにアクセスするというと、Winnyとかtorrentみたいなのを想定してるんでしょうか。 これはかなり、いけてない、感じがしますね。理由は三つ。 ＊hash関数は一方向的＊ 一方向的ということは、探索方法が必要だということになります。テーブルで管理するのでは爆発しますからDHTか何かを使うことになりますが、それってDNSと比較して何が嬉しくなるのでしょうか。DNSであれば一回で済んだアクセスが、DHTであれば複数回になるかも知れません。またコンテンツすべてがhash値を持つと言うことは、解決する側にかかる負担が大きくなると言うことです。解決にはより多くの時間がかかるようになる気がしませんか。やってみないと分からないですけどね。 ＊同一サーバ上のコンテンツが分かりにくくなる＊ 同じサーバの別コンテンツは同時にアクセスされます。yahooのトップページにアクセスすると画像含め100くらいのHTTPネゴが起きるそうです。それ全部が違うハッシュを持つのでしょうか。ハッシュ解決に100msかかるとしたら、yahooのトップページを出すためだけに10秒かかってしまう計算になります。北海道から東京へのアクセスでは、実際にこういうことが起きてるんですよ。 あるいはここの質問サイト、隣同士の質問は別の内容ですが、連続してアクセスされやすいでしょう。アクセスのたびにハッシュ解決問い合わせをすることになりますよね。これも効率的じゃないです。 ＊コンテンツ流通責任範囲＊ 現在のwebの形態には、「誰がコンテンツを持つか」っていう責任範囲があります。コンテンツにhash値を与えて多くの場所に分散させた場合、責任を（中略）コンテンツの削除（以下略）。 ただ、世界を変えてやるくらいの意気込みなら、アリだと思います。 > 一昔前なら誰かがチラとこういうアイデア出せば飛びついて無理やりにでも実装したのに アイディア単体だったらそれこそ70年代にはもう征服されているでしょうね。 まともに利用する土台があってそこに実装したとなれば、今でも大いに評価されます。 OAuthなんか、仕組みはボロボロなのに今とってもアツいですからね。 こういったことを考える場合は、 ・従来と比較して、何が嬉しくなるか をきちんと明示すると、より理解を得やすいですよ。 またセキュリティや認証系を扱う上では、 ・ユーザに何が見えるか ・どこを、何が流れるか がはっきりしないと、話として成立しません。 考えていらっしゃること自体は面白いので、次はぜひ、もう少しわかりやすくお願いします。
その他の回答 (3)
- matoro6173
- ベストアンサー率5% (2/37)
確かに、何かパスワードの保存とか暗号化以外にもハッシュは使えそうな気がしますね。 ただ、一か所での認証以外でハッシュを利用する際はやはり種？の扱い方が問題になります。 どちらにせよ種がばれたら危ないわけなので、一意であるipやドメインのままでも意味は変わらないと思いますが。 プロトコルの例がありますが、実装した場合のハッシュの切り替え方も問題はあるでしょう。 パケットの方に切り替え前、後の情報を持たせるのでしょうか。 持たせないとしたら、切り替え時に遭難するパケットが出てくるでしょう。 可用性がガタ落ちです。
お礼
ご回答ありがとうございました（＾＾） プロトコルは何とかなるだろ程度で言ってみただけだったので 具体的に考えるよい機会になりました（＾＾）
補足
種バレ対策は直接には無くて、変更をしやすくして被害拡大防止が速やかに行えることと、あとは電卓set時の覗きやらは社会的マナーっぽく啓蒙？するしかないかもです。 ipやドメインも名前とその実体という構造は同じなので将来的にはあらゆる階層構造がフラットになってURLボックスに直接ハッシュ値を打ち込むとか？ プロトコルまで行きませんが自分でやってみたことから考えてみると、 ネットの窓口をブラウザのURL入力ボックスとして、 まず独自ドメインを使って自分で決めたURLを入力→そこで開くページにオンラインブックマークサイトへのリンクを書いておいたのでクリック→自分のアカウントのオンラインブックマークサイトが開くのでそこから予めブクマしておいたメールなどの各種サービスへ飛ぶ ここで、オンラインブクマに複数のサービスサイト登録済みだが、事情あって 全てのパスワード(以下pw)を変更したいとする サイト側で対応が必要だが、IDの他にそのサイト専用の種pwをアカウント登録時に設定必須とする この種pwは最初の設定時に入力する以外、二度と画面に表示されることはない オンラインブクマの機能又は、それ専用の機能を持つWebサービスでも良いが（あるとして）、 pwの変更回数を１加算する信号を各サイトに送出 受信したサイトはそのサイト専用種pwを使ってpwを更新 サイト専用種pw＋ID＋変更回数（0始まり）←これを1加算 でハッシュを取ってそれを新pwとする 加算後の変更回数をオンラインブクマ（又はpw自動変更webサービスサイト）へ通知 オンラインブクマのQRコードへ変更反映 こんな風に考えましたが、各パケットの疎通については、現状ではまずいでしょうか？
- Werner
- ベストアンサー率53% (395/735)
> SHA256は衝突未発見です。 ハッシュは原理上必ず衝突が発生します。 たとえば256ビットのハッシュ値を出力するハッシュ関数に 2の256乗パターンを超える入力を与えると 少なくとも１組のハッシュ値は同値になります。 おそらく衝突耐性を持つという話をどこかで見たのでしょうが、 衝突耐性を持つことは衝突しないという意味ではありません。
補足
wikipediaの巨大数の項目に天文学的な巨大数というのがありますがそこの説明によるとハッシュ関数MD5の２の１２８乗でも実質的に０に等しいとありましたので 少なくとも衝突が発見されるまではSHA256でいいかなと思いました。
- Werner
- ベストアンサー率53% (395/735)
> URLのところにハッシュ値を入れれば即対応する内容が表示されればそれでいいのでは？ ハッシュ値にする意味が分からない。 URLは人間に分かりやすいようにと作られたものなのに、逆行以外の何者でもない。 （コンピュータに分かりさえすれば良かったなら、今でもIPアドレスをそのまま打ち込んでいるでしょう。） 今だって、URLのところにURLを入れたら即対応する内容が表示されてるんだからそれでいいでしょう。 > そのIDパス自体もハッシュで決めればいいし ユーザーがハッシュを通す意味がない。 （その必要があるならユーザーのあずかり知らぬバックグラウンドで自動的にやればよい。） ハッシュ関数みたいなプリミティブな技術はエンドユーザーが直接使うようなものじゃないです。 活用なら電子署名とかの応用がたくさんある。 なんか一連の質問を見ているとハッシュについて盛大に勘違いしてるように思えます。 （ひとつだけに絞れる、あたりから少なくとも衝突するということは知らないみたいですし。）
補足
SHA256は衝突未発見です。
お礼
ご回答ありがとうございました。