DBにパスワードを保存する際に、どのハッシュを選ぶか - Yappo::タワシ
というのを速度とハッシュ後のサイズだけみてみた。 安い速いだけが選定基準にはならないって事を注意書きしとく。 # いろいろ追加した md5 : 16 sha1 : 20 sha224 : 28 sha256 : 32 sha384 : 48 sha512 : 64 hmac_sha1 : 20 hmac_sha512: 64 Rate hmac_sha512 sha512 sha384 hmac_sha1 sha224 sha256 sha1 ds_sha1 md5 hmac_sha512 36364/s -- -68% -70% -82% -89% -90% -92% -96% -97% sha512 114943/s 216% -- -4% -42% -67% -67% -74% -87% -90% sha384 119760/s 229% 4% -- -39% -65% -66% -
Kazuho@Cybozu Labs: 秘密鍵を後置している MAC の危険性
« Hash ≠ MAC | メイン | はてな認証 API への攻撃シナリオ » 2006年05月08日 秘密鍵を後置している MAC の危険性 先のエントリについて、結城さんが『「Hash ≠ MAC」の意味』に、まとめてくださっています。ありがとうございます。 16:37 追記: すいません。注1 の仮定が現実的でないように思います。よって、以下は成り立たないの攻撃は現時点では難しいかと。バイナリデータなら、TLV の L を、コリジョンデータの値が異なるところに着地させる可能なのかも。 ついでに、秘密鍵が後置されている場合のリスクについても考えていたのですが、 ハッシュ関数の衝突例が知られている 毎回選択平文攻撃が可能 ゴミデータの挿入が可能 (これは前置型と同等の条件) の３条件がすべて満たされている場合は、危険なんじゃないでしょうか。 というのは、同じハッシュ値をもつ "[ゴミ
Kazuho@Cybozu Labs: Hash ≠ MAC
« Re: はてな認証 API | メイン | 秘密鍵を後置している MAC の危険性 » 2006年05月07日 Hash ≠ MAC ハッシュ関数を MAC (メッセージ認証コード; いわゆる秘密鍵による署名) として使用していけません、という件について。 HMAC の論文を見たところ、様々な攻撃手法について述べてありました。ちなみに、今回のケースは、 Extension Attack です。引用すると、 Consider the "prepend-only" construction: MACk(x) = F(k, x) (i.e., the key k is prepended to the data x and the hash function - with the fixed IV - computed on the concatenated information). Be
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
