Node.js で発生した Hash flooding DoS とその内容について - from scratch
Node.js のセキュリティアップデート 7/11 に Node.js のセキュリティアップデートがリリースされました。 Security updates for all active release lines, July 2017 | Node.js これには複数の脆弱性が報告されており、今回はそのうちの1つの Hash flooding DoS という脆弱性が何なのか、それに対して採用された対策が何なのかについてお話します。 Hash flooding DoS (hashdos) Denial Of Service 、つまりサービス拒否攻撃の一種です。 JavaScript のオブジェクトは内部的にハッシュテーブルとして表現されています。 図はこちらから引用 ハッシュ関数は同じkeyなら同じ値を返しますが、別なkeyなら通常は別な値になります。 ハッシュテーブルのinsert, g
Keccak is SHA-3 - Schneier on Security
Keccak is SHA-3 NIST has just announced that Keccak has been selected as SHA-3. It’s a fine choice. I’m glad that SHA-3 is nothing like the SHA-2 family; something completely different is good. Congratulations to the Keccak team. Congratulations—and thank you—to NIST for running a very professional, interesting, and enjoyable competition. The process has increased our understanding about the crypt
すべてはここから始まった〜SHA-1の脆弱化 ― ＠IT
米国は、現在利用されているすべての米国政府標準の暗号技術を2010年までにより安全な暗号技術へ交代させていく方針を明確に打ち出している。現在、世界中で使われているデファクトスタンダードの暗号技術は、そのほとんどすべてが米国政府標準の暗号技術に準じているため影響は極めて大きい。2010年に向けて現在使われている暗号技術はどのように変わっていくのだろうか（編集部） 2005年2月15日、世界的な暗号の権威であるBruce Schneier氏のBlog「Schneier on Security」で公表された「SHA-1 Broken」という情報は、驚きをもって世界中を駆け回った。現在、ハッシュ関数のデファクトスタンダードとして最も広く利用されているSHA-1に対して、中国・山東大学のXiaoyun Wang氏とHongbo Yu氏、セキュリティコンサルタントのYiqun Lisa Yin氏のチー
OpenSSH 情報 - [misc][暗号]「原理から学ぶネットワーク・セキュリティ 第4回 ハッシュ関数」の問題点
原理から学ぶネットワーク・セキュリティ 第4回 ハッシュ関数：ITproの問題点を挙げていきます. 一通り書きました. 作成中の段階では間違っていた部分があったのを確認していますが, 修正したつもりです. 私も暗号屋ではありませんので, 文章の内容の保証は致しません. 修正の御指摘は歓迎します. 導入部 データ構造としてのハッシュ/ハッシュ・テーブルと暗号技術のハッシュ関数を混同して説明するのは, 誤解を生むおそれがあります. 仮に暗号技術のハッシュ関数の説明の中でデータ構造としてのハッシュに触れる場合でも, 異なるものと説明したほうがよいでしょう. ハッシュ関数の説明として, 一方向性だけが挙げられていますが衝突耐性についても触れておくべきです. 後のコラムで衝突耐性について触れられていますが, 内容は不正確です. ハッシュ関数の実験 この部分の内容に問題はありません. ただし, 先に衝
NIST，新ハッシュ関数アルゴリズムの公募コンテストを開催へ
米商務省の国立標準技術研究所（NIST）は，新しいハッシュ関数アルゴリズムについて，公募形式のコンテストを開催する。NISTのComputer Security Resource Center（CSRC）が明らかにしたもの。NISTは米国時間1月23日，募集するハッシュ関数アルゴリズムの要件などを発表した（PDF文書）。 ハッシュ関数は，データを元の値がわからないように変換する一方向性関数。暗号化や電子署名などで利用する。米国政府は「Secure Hash Standard（SHA）-1」やさらに強力な「SHA-2」といったハッシュ関数を標準として採用し，公的文書の暗号化などに使用している。ただしSHA-1には弱点が存在するとして，米国政府は政府機関によるSHA-1の使用を制限した（関連記事：その1，その2，その3）。 新ハッシュ関数アルゴリズムのコンテストは，かつて暗号アルゴリズムAdv
Kazuho@Cybozu Labs: はてな認証 API の改善案
« Re: 攻撃してください→はてな認証の仮想セッション | メイン | 目指せバイナリアン (C-0.06) » 2006年05月11日 はてな認証 API の改善案 だんだん自分の中でも認証 API の問題が整理できてきたように思うので、改善案を書こうと思います。 まず、そもそも認証 API に何を期待するのか、という点について。 従来の各サイト毎にパスワードを入力する方式は、 ・パスワード管理が面倒 ・HTTPS じゃないので、パスワードがネットワーク上を平文で流れる ・メールアドレスが漏洩するかも (スパム襲来) といった不便さや懸念がありました。しかし、外部の認証 API を使用するウェブアプリケーションについては、これらの問題が解消できるはずです。具体的には、cookie がもれない限り安全な認証 API注1があればベストでしょう。 で、はてな認証 API は、以下の各点を修正
HMAC - Wikipedia
HMAC-SHA1の生成 HMAC (Hash-based Message Authentication Code または keyed-Hash Message Authentication Code) とは、メッセージ認証符号 (MAC; Message Authentication Code) の一つであり、秘密鍵とメッセージ（データ）とハッシュ関数をもとに計算される。 1997年2月、IBMのKrawczykらにより提唱され、RFC 2104として公開されている。また、FIPS PUB 198にも採用されている。 概要[編集] MACは認証及び改竄検出技術の核となるアルゴリズムである。HMACアルゴリズムは、MAC値（タグ）の算出に暗号学的ハッシュ関数を用いる。ハッシュ関数としては、SHA-2やSHA-3など任意の繰返し型ハッシュ関数を適用可能であり、ハッシュ関数Xを用いるHMACは
HMAC: Keyed-Hashing for Message Authentication
H. Krawczyk IBM M. Bellare UCSD R. Canetti IBM 1997年 2月 HMAC： メッセージ認証のための鍵付ハッシング (HMAC: Keyed-Hashing for Message Authentication) このメモの位置付け このメモは、インターネット・コミュニティに対して情報を提供するものである。このメモは、何らインターネットの標準を規定するものではない。このメモの配布に制限はない。 要旨 この文書では、暗号ハッシュ関数を使用してメッセージ認証を行なう仕組みである HMAC について記述する。HMAC は、MD5 や SHA-1 などの反復暗号ハッシュ関数を秘密の共有鍵と組み合わせて使用する。HMAC の暗号としての強度は、使用しているハッシュ関数のプロパティに依存する。 1.はじめに 信頼できないメディア上を伝送し、蓄積される情報の
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
Kazuho@Cybozu Labs: Re: はてな認証 API
« はてな認証 API | メイン | Hash ≠ MAC » 2006年05月06日 Re: はてな認証 API naoya さんありがとうございます、ということで、「認証APIのメモについてのレス」への返答です。 2006/5/7 追記: 1) で述べた MD5 による api_sig の偽装が可能であることを確認しました。この偽装を用いた攻撃は、auth.json および auth.xml については、1) に述べたとおり成功しません。認証リンクについては、仕様として任意のパラメータをハンドリングできる必要があるので、攻撃が成立してします (攻撃者がパラメータを追加することができる)。 よって、認証リンクの署名機能は壊れている、と言わざるを得ないように思います。 3) パラメータ指定の手法について 先にこちらから。 パラメータ指定は先日サポートしました。http://auth.ha
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.jnsa.org/2006/seminar/20061113nsf/data/14_b13_matsui.pdf
NISTが次期ハッシュ関数選定のスケジュールを発表 | スラド