Last-Modified: Mon Nov 27 06:02:45 2006
上野から御徒町に移動したそうなので、そっちに戻る。
とりあえず色々ノーコメント。
馬鹿話もいいんだけど、お久しぶりな人も多いので色々近況問い詰めようと思っていたら失敗。しょんぼりしょんぼり。
そして、横須賀の人は青葉ということでファイナルアンサー。
どこぞやの人のお誘いで上野。 なんかありえない面子になっている気がしますが、まぁそこは気にしない方向ででで。
ていうか、13時集合つったら普通昼飯食べて来るでしょっ。
こんなことなら昼飯食べないで秋葉で時間つぶしてれば良かったよ。
そのまま上野パセラで5時間。おいらは3時間たったところで離脱。
23:30 - 06:00
今日は研究室の構成変更(引っ越し)に参加できないので、 一瞬だけ行って自分の荷物をふくだ席に置かせてもらうことに。 で、マシンとスイッチと液晶しかないと思っていたら、 旧ec(引っ越しおわるまで落ちてる)が2台あって焦る。 ど、どうにかしなきゃ……。
マシン以外は、本とかは休み中は撤退させてるので残りは茶封筒*2と文房具くらい。 あとどでかクッション。これ重要。
というわけで、みんなに謝りたおしつつ 10:40 のバスを狙い撃ちして帰る。 今日は祝日なので休日ダイヤで1時間に2本しかないのですよ。 行きもそのおかげで20分くらい待たされたし。 終バス早いのもそうだけど、もう少し本数増やしてくれてもいいのにね、湘南台住人とかネットワーク繋ぎに大学行く人居るんだし。
お昼は水道橋に寄って魂。
newserを Tiarra 経由にしてみて Tiarra の方が気に入ってきたので、 さっそく aki_* の plum を Tiarra に置き換えてみるテスト。 設定はサンプルの設定ファイルにコメントがかなりちゃんと書かれているし、 かなり気に入ったかも。
なると配りはまだ移行してないので、これはまた後で。
というか、ちゃんと整理し直さないといけないし。
で、新しい aki.irc.nekoruri.jp の逆引きを持つ v6 address を振ってみる。 A record なんてありませんよ:)
Tiarra の方が、特に Multicast あたりの挙動で少しずつ親切になっていてかなり嬉しいかも。 ログファイルのディレクトリもちゃんと自分で作ってくれるし。
service address block のアドレスを omoikane にも付けたので、 そっちでも route6d を上げて経路流す/聞くようにしたんだけど、 少し立つと default route が消える病。 しかも iwato(external link を持っている gateway) 側で rtadvd 上げ直すと直ったりする。
で、少し調べて iwato で上げている ripngd が default-information originate していなかったことにようやく気付く。
なるほどぅ。
というわけで、FreeBSD 環境下で /compat/linux で動かして見た。
あとは、一旦 root で動かしてポート番号を特権ポートじゃ無いものにして、 chmod して一般ユーザで起動とかそんな感じ。
色々展開の会。ていうか、
キタ━━━━━━━━(゚∀゚)━━━━━━━━!!!!
ここまで色々はっきりかかれると、 シリーズとしてのテーマがはっきりしてきますな。
2004年3月12日 22:00 より1時間程度、国内IRCNET網の一斉メンテナンスを行います。
上記時間帯はIRCサーバへの接続が出来なくなりますが、ご理解下さい。作業内容は OSのアップデート及び IRCサーバのバージョンアップを行います。
また、長時間、海外への接続が切れておりましたが、irc.media.kyoto-u.ac.jp のサーバより海外への接点を設ける事により、海外との接続の安定化を図る予定です。作業完了次第、ご利用になれます。
以上宜しくお願いします。
というわけで、22 時からメンテナンスです。
ともちゃも書いているように、
各チャンネルの topic, op, voice、忘れがちな各種チャンネルフ
ラグの保存をお忘れなく。
これだったら、BBS等で告知するノード情報(初期ノード) として、 IP アドレスに公開鍵(Key_1)を加えるだけでいいような気がします。
Tomo さんの例に合わせると、
A に既に接続した人には A の公開鍵 Key_1 は既知であり
Hash[ Key_1, Name ] を作れてしまうので、
わざわざハッシュを取る必要性はなさそうに思えます。
むしろ、せっかく公開鍵を用意するのなら、
Name を Key_2 で署名して EKey_2[ Name ] を B に渡すべきでしょう。
そうすれば、BBS 上から IP アドレスとセットで入手した Key_1 によって検証することができます。
まぁ、そのままだと鍵が長いので、
あくまで BBS にはハッシュ値だけでもいいかもしれませんが、
その場合も、A が Key_1 を渡した後に既知のハッシュ値から Key_1 を検証し、
さらにその Key_1 を用いて処理すべきです。
ただ、これは OnePointFirewall のような、通信路上だけで待っているような場合だけにしか適用できません。 つまり、悪意を持つノードが BBS に書き込んでしまうような攻撃には対処のしようがないです。
通信路上の man-in-the-middle 攻撃を想定したときに、 有効な対処法は接続相手に関する追加情報をあらかじめ共有し、 相手を確実に認証するというのは正しいやり方です。 その認証に対して用いられるのが SSL や SMIME であれば CA、PGP であれば第三者による署名であるわけです。 ですが、アプリケーションとしてたとえば Winny のような「誰が参加するかわからない」ネットワークの場合は、 そういった他社による署名を利用できません。
そこで、相手が最初に自称した情報を信頼することになるわけですが、 Winny であれば初期ノード掲示板にかかれた IP アドレスだけですし、 WASTE のように公開鍵を利用するものもあります。 当然ながら、これらはその「自称」をそのまま信用せざるをえないため、 悪意を持つクライアントが自発的に参加してくるようなケースには対処できないというわけです。
ちなみに、どうでもいいことですが、 個人的には公開鍵対は暗号化を行う視点を重視して Ke(公開鍵:encrypt) と Kd(個人鍵:decrypt) と呼ぶのが好きだったりします。
そして手動で TrackBack 送ろうとしたら送り先を間違えました。ごめんなさい(つД`)
とりあえず光が来たこともあって、 (ようやく) SoftEther 環境を整えてみた。
HUB が Win2k Server で動いていてブリッジが出来ないので、 別の XP Professional なマシンに依存しているところがいけてない。 HUB を XP で動かすか、Win2k Server を Win2003 Server にするか、 あるいは ActiveDirectory を捨てて Win2k Server を WinXP にするか。 あと、大穴としては SoftEther を捨てて別の VPN に乗り換えるか。 でも SoftEther + ブリッジが一番楽なんだよなぁ。