`OpenBSD で scheme のアプリ開発' みたいなことをやってます。
foo(char *s)
みたいな関数があって、 内部で s をいじってて、 なおかつ s の長さをチェックしていないライブラリを発見。
中身はこんなの。
foo(char *s)
{
char buf[N]
...
strcpy(buf, s);
...
}
こういうときは、ふつう
foo(char *s, size_t len)
{
char buf[N]
...
strlcpy(buf, s, sizeof(buf));
...
}
だよねえ。
修正案を拙い英語で送ってみる。
via: http://yendot.org/
IETF のドラフト。既存のハッシュ関数を使う。SHA1 なら CR-SHA1、MD5 なら CR-MD5 等。
上のドラフトでは ASN.1 の DER エンコードを例にしているので、読んでみる。
ASN.1 の書式はこう。
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
digest OCTET STRING }
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
CR-MD5 を選択した場合、 CR-MD5 の OBJECT IDENTIFIER は 1.3.6.1.4.1.10471.6.4.3.1 になる予定で、 これを DER エンコードすると、
30 1f
06 0b
2b 06 01 04 01 d1 67 06 04 03 01
04 10
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX は乱数列になる。
例えば、 XX が 109de96f90aa7d08814c32fc456f9e6e6a となるような ASN.1 ストリームと 平分 f8f04799c4ea178042b604660a6fe3f166599a815aa9e2edf4 を受け取ったとき、
digest(平分) => MD5(4f63cc47a5cc2d2e563b54cd0b38f5d7)
digest(乱数列 + 平分) => CR-MD5(faa4702ab6e7fa890627192cd6cc6333)
となる。なるほど。入力を制御しようという試みか。これって salt の発想そのもの？
http://isc.sans.org/diary.php?date=2005-03-06
Windows XP と 2003 Server が対象らしい。
ソースとターゲットが同ポート同 IP の SYN bit の立ったパケットを送られると不安定になる、ってをいをい。
Windows XP Home Edition が無効ってのもよくわからんな。
世の中にはいろんな人たちがいる。 その中でも、あなたにとってコミュニケーションをとる価値のある人と、 あなたの意思に関わりなくメッセージを読ませたがる人がいるのではないかと思う。
もちろん、あなたが必要としているのは前者であって、後者ではない。
それを振り分ける技術が、 メールだったらホワイトリスト/ブラックリストだったりベイジアンフィルタだったりするわけだ。
でも、こういった技術はかなり広汎に試されているので、ここで説明するのは置いておいて、 今回はもう少し変わり種の手法である hashcash を紹介しよう。
ここで、突然ちょっとした数学の話になる。 まあそんなに難しくはないので、最後までお付き合い願いたい。
ある文字列 S が与えられたとき、もうひとつの文字列 s と連結した文字列(トークン) S + s の ハッシュ値 H の 左 n bit がすべて 0 になる、そのような s はどんな文字列だろうか。
計算してみないとわからないって？ そう。実際に s を 0 から順に H を計算して、 実際にそうなっているのかどうか確かめてみなければわからない。ここがミソ。
あなたがスパムメールにうんざりさせられているのなら、 この条件を満たす H のスタンプの入ったメールのみ読めばいい。 とうぜん、あなたの友人の同意も必要だけど。
久しぶりにメールのやりとりをしたいと思い立ったあなたの友人も、 毎週メッセージを替えて送ってくるスパマーも、 誰もが衝突するハッシュを発見するまで計算しなければならない。 「私と会話したいなら、ちょっとだけあなたの電力と時間をください」というのが、 hashcash なわけ。 個人の間でメッセージをやりとりするなら計算は 1 回きりだけど、 スパマーは大量にメッセージをまき散らさないといけないから、 それこそ何度も何度も違うハッシュを計算しないといけなくなる、というしかけだ。
それでは、実際どうなっているのか hashcash の公式ページからダウンロードして試してみよう。
コンパイルできただろうか？ それではさっそく n = 20 で s を検索してみよう。
$ hashcash -mb20 foo hashcash token: 1:20:050303:foo::kN687vWdyW8jUw3+:0000000000000072LM
しばらく計算した後、上のようなトークンが出力される。 実行するごとに乱数でかき混ぜるのでトークンのエントリの真ん中より右側は毎回違う値が出力されるはずだ。 ちなみに、いちばん右の 0000000000000072LM が s に相当する文字列である。
foo は他の人のトークンとぶつからないように、 実際に使用するときはユニークな文字列の方がいいだろう。 例えばメールアドレスのような。
本当にこれが正しいトークンなのか確かめてみよう。
$ echo -n "1:20:050303:foo::kN687vWdyW8jUw3+:0000000000000072LM" | \ openssl sha1 000004a5a3839d2d4e696d2ec4af01cf6340cfba
左 20 bit が 0 になっているのがわかるだろうか。
以上で原理が理解できたと思う。
次に応用なのだが、 javascript で実装してみたのがこれ。
javascript は実行速度が遅いので n = 10 である。
これを使って、 このページの くっつき BBS と連携させてみたので試していただきたい。
検索空間は 0 から 210 なので、 もしかすると衝突を発見できないかもしれない。 そのときは発見するまで計算ボタンを気が済むまで連打してほしい。
確認しておくけど、計算結果であるトークンは一回きりしか使えないことに注意。 なぜだかわかるよね？ それを実現するためには毎回データベースへ使用済みトークンを登録していけばいい。
最後に、ここまで読んでくれた人への宿題。
リンク
via: http://blogs.yahoo.co.jp/tmata_yaho/91744.html
なるほど、攻撃者がどうしようもなく愚かであったならば、その議論は成り立ちますが、 それには、この攻撃アルゴリズムを使い続けることが前提となります。
いまのところこの論文は公開されていないようですが、公開されてしまえば、 攻撃アルゴリズムを洗練することができるわけです。
実際、 SHA-1 のラウンドが残り 46/80 と言われていた のが 2004 年の 8 月です。 それから残りのラウンドの攻撃には半年しかかからなかったことになります。
セキュリティの攻撃への激しさといえば、極端な例が上のリンクにありますが、 ToyoCrypt は 2002 年に 296 だったのが、 2004 年には 229 のオーダになってしまった、と報告にあります。
これはハッシュではなくストリーム暗号なので簡単に比較することはできませんが、 弱いと判断された暗号やハッシュのアルゴリズムは徹底的に攻撃方法を解析される、 というのがこの業界のようですので、 SHA-1 の命運は尽きた、といって間違いないでしょう(これからどれくらいのオーダまで減らすことができるか見物ですね)。
それにセキュリティはいつも安全側へ振っておくほうがよい、 とされています(問題があってからでは遅い)ので、 安全であると主張するには慎重であったほうがいいと思います。
追記:
リサーチノートが公開されたそうです。
ねた元:武田氏のブログ
