具体的にはトップページを blog ベースに作り変えました。 また最近はもっぱら Vox で遊んでいますので， 今後も Spiegel の記事が読みたいという奇特な方はいずれかをご利用いただけると嬉しいです。 ここの記事群はそのまま残しておきます。 ここにあるコンテンツたちがちょっとでもお役に立てば幸いです。

なお， あなたが優れたテキストエディタをお探しならここの記事は全く参考になりません。 そういう事例もあるよってことで軽く読み飛ばしていただければ幸いです。

昔はフリー（自由または無料）なソフトを使うことを品質上の保証がないという理由で忌避する企業が多かったのですが， 最近は FOSS の台頭によって品質に対する不安感は薄らいでいっている気がします。 むしろ（少なくとも汎用アプリケーションに限っては）製品の利用に際し排他的なライセンスを結ぶほうがリスクになりつつあります。 プライベートや仕事などで複数のコンピュータを渡り歩いている人が増えてきています。 故にそのソフトウェアが「使えるソフト」であればあるほどライセンスの問題がのしかかってきます。

しかしそうは言っても長年（数えてみたら12年以上）秀丸エディタを使って禄を食んできた身としては， それによって染み付いた癖のようなものはどうしようもありません。 もう「秀丸がないとものが考えられない」って感じで「秀丸」依存症と言ってもいいかもしれません。 なので乗り換えるにしてもできるだけ秀丸エディタの操作感覚に近いものでないと困るわけです。 さあ， 困った。

ネットを少し漁ってみましたがあまり有用な情報はないようです。 その中でも比較的参考になったページをいくつか挙げておきます。

• エディタ -- オンラインソフト紹介 -- 林檎の木
• フリーエディタ１７選！
• 窓の杜 - テキストエディター

これらのページで挙げられている以外にもいろいろあったのですが， 今回はスルーします。 何せ早く決めないと「メモ帳」で仕事する羽目になっちゃいますから（笑）

最終的に TeraPad とサクラエディタとでどっちにしようか悩んだけど， 結局サクラエディタに決めました。 サクラエディタのインストールパッケージは関連ファイルや設定があらかじめ同梱されていて， インストール後すぐに使うことができます。 また SakuraDown を使えばソフトのアップグレードも簡単にできます。 この辺結構大事。

サクラエディタに決めた理由は2つ。 ひとつは以前の仕事でサーバのメンテ用に使ったことがあること， もうひとつは設計コンセプトが秀丸エディタに似ている（ように私には見えた）こと， です。 ユーザインタフェース設計で一番重要なのは「変えない」ことです。 実はこれが一番難しい。 またあるソフトから別のソフトに乗り換える際にもこの点が一番ネックになります。 学校教育の現場でコンピュータ環境が変わって「Microsoft製品でないと「高校と違う」という苦情」が聞かれるそうですが， ある意味その学生さんたちに同情します。 「操作」というのは頭よりも身体で覚える部分が大きく， それだけ変化に対する適応が遅れる傾向にあります。 だから極力「操作」は変えてはいけないのです（特に年取るとねー）。 まぁでもソフトは絶えず変化するものですし， いつかは思い切らないといけないんですけどね。

次回は（もし次回があるのなら）サクラエディタを使ってみた感想等を書いてみましょうか。

誕生日祝いに猪をご馳走してくれるというので， のこのこついて行きました。 派手な看板とかはないので気をつけてないと通り過ぎてしまいそうになります。 私は初めてだったのですが， 結構老舗のようです。

最初はぼたん鍋をいただく予定だったのですが， メニューを見て急遽しゃぶしゃぶに変更（ちなみにぼたん鍋は予約が必要なようです）。 いや，ぼたん鍋なら田舎の温泉旅館とかでも食べられますがしゃぶしゃぶはねぇ。 猪の肉は捕ったときにすぐに血抜きをしないと臭みが残ってしまうのですが， ここのお肉は全く臭みもなくとても美味しかったです。 そうそう， 刺身もいただきました。 これまた美味。 いい思いをさせていただきました。

次こそはぼたん鍋かな。

猪料理 深山 薬研堀店

広島県広島市中区薬研堀3-14 （地図）
電話 082-240-3707
中国山地を駆け巡り、木の実をたっぷり食べた天然の猪の肉を使った広島を代表する料理です。

今回は飲み屋さんじゃなくてケーキ屋さん。 どうも私はパシられる体質のようで， 飲み屋でもいきなりケーキを買いに行かされたりするのですが， そんなときでも慌てなくても大丈夫。 広島流川近辺には私のような不遇の客を助けてくれるお菓子やさんがいくつかあります。 「わがままおばさんのシュークリーム」もそのひとつです。

「わがままおばさんのシュークリーム」のお店は市内にいくつかあるようですが， 私はこの流川店でよく買います。 場所柄なのかサラリーマン風のおじさんもよく利用するみたいです。 どのケーキもみんな美味しいのですが， 今回は写真にあるようなフルーツたっぷりのケーキを持っていきました。 もちろん行きつけのお店の誕生日イベントに献上するためです。 甘さ控えめで甘いものが苦手な方にも結構評判よかったです。

これからもきっとちょくちょくお世話になるお店になるでしょう。

わがままおばさんのシュークリーム 流川店

広島県広島市中区堀川町3-6 （地図）
電話 082-542-0141

この前まで暑いと思っていたのに， もうめっきり秋になってしまいました。 そんな感じの空。

JSONP （JSON with Padding）というのは JSON のデータフォーマットにちょっとした記述を加えて JavaScript の関数として呼び出せるようにしたものです。 JSONP については以下の記事に簡単な説明があります。（多分この記事が初出だろうという話です）

• Remote JSON - JSONP

{ "name" : "Yasuhiro ARAKAWA" }

JSONP ではこのデータに記述を加えて JavaScript 関数のようにしたものです。 分かりにくいですね。 具体的にはこのように記述します。

callback( { "name" : "Yasuhiro ARAKAWA" } );

"callback" の部分は関数の名前として使えるものなら何でもいいです。 例えば

funclist[1234]( { "name" : "Yasuhiro ARAKAWA" } );

でも構いません。 何でこんなことをするかというと， JavaScript で他ドメインの JSON データを非同期で読み込むことができるからです。

以前「入門 JSON」にて， JavaScript でリモートのデータを呼び込む際に2通りの方法があると説明しました。 ひとつは XMLHttpRequest クラスを使う方法， もうひとつは JavaScript ソースとしてインクルードする方法です。 「クロスドメインの制約」からXMLHttpRequest を使う方法では読込先が他ドメインの場合は使えません。 そこでデータを JSONP の形式にして JavaScript のソースとしてインクルードしてしまうわけです。 また JSONP は関数呼び出しの形式になっているので， その関数の処理を別に記述することでコールバック関数のように機能します。

JSONP を上手く処理するためのクラスを公開しておられる方もいます。

• JSON and the Dynamic Script Tag: Easy, XML-less Web Services for JavaScript

• http://del.icio.us/feeds/json/spiegel?callback=hundler

hundler([ ... ])

[ ... ] の部分が JSON 形式の配列データになっているわけです。

ところで余談ですが， ついに JSON フォーマットが RFC4627 として正式な仕様になりました。 メディアタイプも application/json と決まりました。 以前「入門 JSON 2」で 「JSON ではこのオブジェクトがデータの基本になっています」 と書きましたが， RFC4627 によると

"A JSON text is a serialized object or array."

とあり， オブジェクト（＝連想配列）と配列のどちらでもいいようです。

では JSONP データと JSONscriptRequest クラスを使ってブックマークのリストを作ってみましょう。

<script type="text/javascript" src="/js/jsr_class.js"></script>
<div id="bookmark"></div>
<script type="text/javascript">
  var oJsr = new JSONscriptRequest('http://del.icio.us/feeds/json/spiegel?callback=hundler');
  oJsr.buildScriptTag();
  oJsr.addScriptTag();

  function hundler(data) {
    var ul = document.createElement('ul');
    for (var i=0, post; post = data[i]; i++) {
      var li = document.createElement('li');
      var a = document.createElement('a');
      a.setAttribute('href', post.u);
      a.appendChild(document.createTextNode(post.d));
      li.appendChild(a);
      ul.appendChild(li);
    }
    document.getElementById('bookmark').appendChild(ul);
    oJsr.removeScriptTag();
  }
</script>

実行結果：

JSONscriptRequest クラスには3つのメソッドがあります。 1つ目は buildScriptTag メソッド。 コンストラクタ引数の URI から script 要素（タグ）を生成します。 2つ目は addScriptTag メソッドで， buildScriptTag で生成した script 要素を HTML の head 要素内に追加します。 簡単に言うと addScriptTag メソッドを呼び出した時点で URI 先のデータが読み込まれコールバック関数が実行されます。 3つ目の removeScriptTag メソッドは生成した script 要素を HTML の head 要素から削除します。 後始末係ですね。

JSONP や JSONscriptRequest クラスは JSON データの使い勝手を向上させますが， 「入門 JSON」でも指摘した通り， この方法は常にセキュリティ上のリスクが伴うことを忘れないでください。 とくに JSONP はサーバ側の実装によっては重大な XSS 脆弱性を抱える可能性があります。 この記事が参考になれば幸いです。

参考：

• RFC4627 -- The application/json Media Type for JavaScript Object Notation (JSON)
• Remote JSON - JSONP
• JSON and the Dynamic Script Tag: Easy, XML-less Web Services for JavaScript
• JSONScriptRequest
• JSONP
• JSONPを用いてクロスドメインで情報を取得する
• ブラウザからJSONで呼び出せるサービス一覧

• 「惑星」の定義の原案、公開へ

原案のポイントを挙げておきましょう。

1. 水星から海王星までの8つの惑星を Classical Planet と呼称する。
2. 冥王星を含む海王星以遠天体（TNO; Trans-Neptunian Object）のうち新しい惑星定義に当てはまるものを Plutons と呼称する。
3. Classical Planet および Plutons 以外で新しい惑星定義により惑星に昇格した天体を Dwarf Planet と呼称する。
4. 上記以外の太陽系天体（小惑星（asteroid），惑星以外の TNO，彗星，その他の小天体）を Small Solar System Bodies と呼称する。
5. これまで使われてきた小惑星（minor planet）という呼称は廃止する。

太陽系の惑星はその組成や軌道要素などから「地球型惑星（Terrestrials）」と「木星型惑星（Jovians）」の2つに分類されることが多いですが， 冥王星はどちらのタイプでもありませんでした。 Plutons という呼び名はその隙間を埋めるものと考えられます（ただし Terrestrials も Jovians も IAU が正式に定めた名前ではありません）。 また「小惑星（minor planet）」という呼び名が廃止されたことも大きいです。 もともと「小惑星（minor planet）」という呼び名は火星と木星の間にある天体群を指すものとして使われ始めたのですが， 定義が曖昧なまま使われていて asteroid だけでなく TNO も「小惑星（minor planet）」に含まれていました。 「小惑星（minor planet）」という呼び名の廃止はそうした曖昧さを排除した結果であると見ることができます。

さて， この原案を元に議論が進められたわけですが， 24日の議決直前までもめにもめたようです。 もめた原因をいくつか挙げてみます。

• 今回の定義は太陽系以外の恒星系にも当てはめるのか。 連星系や褐色矮（わい）星を含む系はどうするのか。
• 新しい惑星定義では惑星の形成過程が考慮されていない。 2003UB313 以外にもこの定義に合う天体はいくつかあり惑星の数が増えすぎる可能性がある。
• Plutons という呼称は似た言葉が他にもあって紛らわしく使いにくい。
• 連惑星の定義に違和感がある。

焦点はやはり冥王星の処遇をどうするかでした。 決議案は何度か修正されましたが何とか冥王星を「惑星」に含めたいという PDC の思惑が透けて見える感じでした。 冥王星はアメリカ人の科学者が発見した唯一の惑星なので， その辺の政治的思惑があるんじゃないかと勘繰られたりしています。 冥王星を惑星に含めるならどうしても他の TNO も含めざるを得ません。 冥王星・カロン以外で原案の惑星定義を満たす TNO としては昨年話題になった 2003 UB313 が挙げられていますが， 他にもいくつか候補はあります。 例えば2004年に発見された「セドナ」はカロンよりも大きいと考えられています。 また2002年に発見された Quaoar や2004年に発見された Orcus はセレスより大きいと考えられ， 原案の惑星定義を満たす可能性があります。

原案では（発見当時冥王星の衛星と考えられてきた）カロンも惑星になるとあります。 惑星の周りをまわる天体で惑星との共通重心が惑星の外部にあるものは衛星ではなく惑星であると見なしているようです。 つまり冥王星とカロンは連惑星になっているわけです。 しかしこの定義についても多くの異論があるようです。 例えば地球の衛星である月ですが， 潮汐作用によって徐々に（年に3.74cm）地球から遠ざかっています。 じゃあ遠い将来地球-月の共通重心が地球の内部から外れれば月も惑星になるのか， という疑問が涌きます。 しかし実際には， ある天体が衛星か連惑星のひとつかという問題は共通重心だけでなく， 質量比とか回転系における遠心力ポテンシャルとか様々な要素を加味して決まるものだ， という主張もあるようです。

こうした議論を経て最終的な決議案が出されました。 以下に引用します。 （日本語訳は「国立天文台 アストロ・トピックス (232)」を参考にしています）

IAU Resolution: Definition of a Planet in the Solar System （IAU 決議: 太陽系における惑星の定義）

Contemporary observations are changing our understanding of planetary systems, and it is important that our nomenclature for objects reflect our current understanding. This applies, in particular, to the designation 'planets'. The word 'planet' originally described 'wanderers' that were known only as moving lights in the sky. Recent discoveries lead us to create a new definition, which we can make using currently available scientific information. （現代の観測によって惑星系に関する我々の理解は変わりつつあり、我々が用いている天体の名称に新しい理解を反映することが重要となってきた。このことは特に「惑星」に当てはまる。「惑星」という名前は、もともとは天球上をさまようように動く光の点という特徴だけから「惑う星」を意味して使われた。近年相次ぐ発見により、我々は、現在までに得られた科学的な情報に基づいて惑星の新しい定義をすることとした）

RESOLUTION 5A （決議5A）

The IAU therefore resolves that planets and other bodies in our Solar System be defined into three distinct categories in the following way （IAU はここに我々の太陽系に属する惑星及びその他の天体に対して以下の3つの明確な種別を定義する）:

1. A planet¹ is a celestial body that (a) is in orbit around the Sun, (b) has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape, and (c) has cleared the neighbourhood around its orbit. （planet¹ とは、 (a) 太陽の周りを回り、 (b) 十分大きな質量を持つので、自己重力が固体に働く他の種々の力を上回って重力平衡形状(ほとんど球状の形)を有し、 (c) その軌道の近くで他の天体を掃き散らしてしまっている天体である）
2. A dwarf planet is a celestial body that (a) is in orbit around the Sun, (b) has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape², (c) has not cleared the neighbourhood around its orbit, and (d) is not a satellite. （dwarf planet とは、 (a) 太陽の周りを回り、 (b) 十分大きな質量を持つので、自己重力が固体に働く他の種々の力を上回って重力平衡形状(ほとんど球状の形)を有し²、 (c) その軌道の近くで他の天体を掃き散らしていない天体であり、 (d) 衛星でない天体である。）
3. All other objects³ orbiting the Sun shall be referred to collectively as "Small Solar System Bodies". （太陽の周りを公転する上記以外の他のすべての天体³ は「Small Solar System Bodies」と総称する）

¹The eight planets are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. （8つの planet とは、水星、金星、地球、火星、木星、土星、天王星、海王星である）
²An IAU process will be established to assign borderline objects into either dwarf planet and other categories. （基準ぎりぎりの所にある天体を dwarf planet とするか他の種別にするかを決める IAU の手続きが制定されることになる）
³These currently include most of the Solar System asteroids, most Trans-Neptunian Objects (TNOs), comets, and other small bodies. （これらの天体は、小惑星（asteroid）、ほとんどの Trans-Neptunian Object (TNO)、彗星、他の小天体を含む）

RESOLUTION 5B （決議5B）

Insert the word "classical" before the word "planet" in Resolution 5A, Section (1), and footnote 1. Thus reading （5Aの決議 1 の「planet」の前に「classical」を挿入する。つまり）:

1. A classical planet¹ is a celestial body . . . （classical planet¹ とは . . .）

and

¹The eight classical planets are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. （8つの classical planet とは、水星、金星、地球、火星、木星、土星、天王星、海王星である）

---

IAU Resolution: Pluto （IAU 決議: 冥王星）

RESOLUTION 6A （決議6A）

The IAU further resolves （IAU はさらに以下の決議をする）:

Pluto is a dwarf planet by the above definition and is recognized as the prototype of a new category of trans-Neptunian objects. （冥王星は上記の定義によって dwarf planet であり、 Trans-Neptunian Object の新しい種族の典型例として認識する）

RESOLUTION 6B （決議6B）

The following sentence is added to Resolution 6A （6Aの決議に加えて次の文を入れる）:

This category is to be called "plutonian objects." （この種族を「plutonian objects」と呼ぶ）

原案からの変更点をいくつか挙げてみます。

• 今回の惑星定義を太陽系天体に限定した。
• 惑星定義がシンプルかつより厳密になった。
• 天体の分類もシンプルになり (classical) platent, dwarf planet, Small Solar System Bodies の3つに集約された。
• セレス，カロン， 2003 UB313 についての記述が削除された。
• 「Plutons」から「plutonian objects」へ名称変更。

(classical) platent と dwarf planet との最大の違いは 「その軌道の近くで他の天体を掃き散らしてしまって」いるかいないかです。 これは惑星の形成過程を考慮した条件のようです。 セレスや（冥王星等の） TNO はこの点で (classical) platent になれません。 またセレス，カロン， 2003 UB313 についての記述が削除されたのも見逃せません。 これらの天体については今後の議論で， ということなのでしょう。 （おそらく dwarf planet に数えられることになると思いますが）

採決は 5A, 6B, 6A, 6B それぞれで行われました。 結果 5A と 6A は可決されましたが 5B, 6B は否決されました。 すなわち「classical platent」および「plutonian objects」という名称は使わないことになります。

今後ですが， 今回の議決で新たに定義された言葉を翻訳する作業があります。 もう一度新たに定義された言葉を挙げておきましょう。

• planet
• dwarf planet
• Small Solar System Bodies

planet は今後もそのまま「惑星」があてられるでしょう。 余談ですが， 「惑星」という言葉は日本で作られた造語らしいです。 『天文月報』2000年12月号の「20世紀の落日を浴びて」（斉藤国治 著）によると， この言葉は長崎の通詞であった本木良永（1735-94）という人が造ったようです。 dwarf planet には今のところ「矮惑星」をあてているところが多いようです。 「"dwarf"は「普通より小さい」という意味の英単語ですから、"dwarf planet"をなじみのある日本語にすれば「小惑星」に」という意見もあるようですが， 「小惑星」という語は既に濫用されている（かつての minor planet も asteroid も日本語では「小惑星」と呼ばれている）ので微妙なところです。 Small Solar System Bodies には「太陽系小天体」といった語をあてている人もいます。

ところで Trans-Neptunian Object （TNO）は最近の天文学の話題ではよく使われる語です。 国立天文台のアストロ・トピックスでは「トランス・ネプチュニアン天体」とそのままカタカナにしていますが， メディアによっては「海王星以遠天体」と書いてるところもあります。 ちなみに TNO はエッジワース・カイパーベルト天体（EKBO; Edgeworth-Kuiper Belt Object）を含みます。

和名が決まれば次は教科書や『理科年表』等の改訂作業が待っています。 来年度に間に合わせるとなると日程的にかなりきついのではないかと思いますが， どうなりますやら。（教科書は2008年度以降に対応するようです）

今回の惑星再定義は私たちの中で長年染み付いてきた「通念」を書き換える作業だと言えます。 冥王星が発見されたのは1930年ですが， 私たちは既に「太陽系の9つの惑星」「水金地火木土天海冥」などというフレーズが頭に染み付いています。 PDC がぎりぎりまで惑星から冥王星を外すことができなかったのも， これまでの「通念」を拭いきれなかったからだと思います。 故に今回の作業は「星座の数を88個に決めた以来の大仕事」と言われるのでしょう。 新しい定義が人々の間で定着するまでにはもう少し時間がかかると思います。

「理性が最良の選択をした」という見方が結構多いように見受けますが， 私はそれは少し違うと思います。 近年観測技術は飛躍的に向上しています。 惑星再定義はそうした背景の元で積みあがった沢山の科学的事実（ファクト）によって必然的におこったものだと思います。 とはいえ今回の惑星再定義もなお曖昧な部分を残しています。 例えば太陽系以外の星系については今回の定義を適用できません（参考にはされるでしょうが）。 また惑星と衛星の違いについても曖昧な部分を残しています。 しかしこれらについても更なるファクトの積み上げによって新たな知見が得られることでしょう。 そして得られた知見はいつの日か別の「再定義」によって私たち一般の人にももたらされる筈です。

科学は新たなファクトによって常に書き換わります。 しかし一般の人の「通念」を覆すほどの書き換えはめったに起こることではありません。 このような大きなイベントに立ち会うことができたのは本当に幸運だと思います。 皆さんもこの機会に宇宙のこと太陽系のことについて奥深さ雑多さを感じていただければと思います。

参考：

• The IAU draft definition of "planet" and "plutons"
• The Final IAU Resolution on the definition of "planet" ready for voting
• IAU 2006 General Assembly: Result of the IAU Resolution votes
• 「惑星」の定義の原案、公開へ
• 「惑星」の定義、総会での議論続く
• 「惑星」の新定義案、総会での採決へ
• （速報）太陽系の惑星の定義確定
• 惑星定義に関する経緯と解説
• 「惑星」の定義について
• IAU Redefines Planet
• Pluto is NOT a Planet
• 【特集・太陽系再編】（1）太陽系の外へ広がる影響
• 【特集・太陽系再編】（2）惑星は増え続けるか
• 【特集・太陽系再編】（3）「小惑星」が消える
• 【特集・太陽系再編】（4）守られるか、冥王星の地位（前編）
• 【特集・太陽系再編】（4）守られるか、冥王星の地位（後編）
• プラハで太陽系が変わる歴史的瞬間
• 【特集・太陽系再編】まとめ
• 新しい惑星の決議案
• 太陽系の新定義-プラハでの歴史的瞬間
• 冥王星が惑星からはずされた理由
• 「惑星の定義」決定に対するコメント （必見です）
• 「惑星の定義」が意味するもの （日本惑星科学会による「惑星の定義」に関する声明文）
• 惑星の定義決定 まとめリンク （整理されていて大変参考になります）

お盆時期を少し外して実家に帰っていました。 帰って早々庭の花など眺めていたら捕食中のカマキリが自慢げにこちらを見ているので（単にビックリして固まっていただけかもしれませんが）， 思わず写真を撮ってしまいました。 これがマヌケなことにストロボが ON になっていてカマキリ君を驚かせることに。 いや， 本当にすまん。

今回は次期 OpenPGP ドラフト案（RFC2440bis）を基準に一覧を作成しました。 最後に参考となるサイト等も紹介していますのであわせて参考にしてください。

RFC2440bis では， FIPS PUB 186-3 draft に従って， DSA アルゴリズムが拡張されます。 また RSA についてアルゴリズムの解説が追加（"12.1. PKCS#1 Encoding In OpenPGP"）されています。 なお pub 20 (Elgamal Encrypt or Sign) はアルゴリズム上の欠陥が発見され廃止になりました。

• [Announce] GnuPG's ElGamal signing keys compromised

共通鍵暗号アルゴリズム（Symmetric Key Algorithms）

sym 5 (SAFER-SK128), sym 6 (DES/SK) は RFC2440bis で廃止になりました。 なお OpenPGP では CFB mode （の変型; "12.9. OpenPGP CFB mode"）で暗号化を行います。

ハッシュ・アルゴリズム（Hash Algorithms）

RFC2440bis において hash 4 (double-width SHA), hash 5 (MD2), hash 6 (TIGER/192), hash 7 (HAVAL-5-160) が廃止になり， hash 8-11 (SHA224/256/384/512) が追加されました。

圧縮アルゴリズム（Compression Algorithms）

comp 3 (BZip2) は RFC2440bis で追加されました。

S2K (String-to-key)

S2K は共通鍵暗号用の鍵を生成する際に使われるアルゴリズムです。

参考

• RFC2440 （日本語訳）
• RFC2440bis
• 電子政府推奨暗号の仕様書
• 暗号の話
• デファクトスタンダード暗号技術の大移行 第3回 これだけは知っておきたいアルゴリズム～共通鍵暗号編
• デファクトスタンダード暗号技術の大移行 第4回 これだけは知っておきたいアルゴリズム～ハッシュ関数・公開鍵暗号・デジタル署名編
• OpenPGP 関連リンク集

暗号技術入門

posted with 簡単リンクくん at 2006. 8.10

結城 浩著
ソフトバンクパブリッシング (2003.9)
通常24時間以内に発送します。

オンライン書店ビーケーワンで詳細を見る

かなりの枚数の写真を撮ったのですが， ろくに準備もしなかったため（三脚も無し）みんなブレブレ。 その中から比較的まともそうなのを Flickr にアップしました。 この記事では更にその中からいくつか紹介します。

今回は幸いなことに天気は良かったのですが， 風の向きや風力がイマイチでこんな感じに煙が漂ってしまっています。 遠くから見たら火事かなんかと間違えちゃうんじゃないだろうか。

結構カラフルです。 最近は高い建物が多くなって下のほうはこんな感じであまり見えなかったりします。 まぁ全部見たかったら会場に行けっちう話なのかもしれませんが。

蝶々がいっぱい飛んでいるような感じ。 個人的には好きです。 でも， 煙で見えにくいんですよ。

これも煙で分かりにくいですが， 変わった形の花火ですよね。 こういう変り種もいっぱい上がりました。 他には土星とか魚とかしゃもじの形をした花火とか。

これはもう最後のほうでかなり乱れ撃ってます。 思ったよりも高く上がったのでフレームを外してしまいました。 ペコリ。

まず， 拙文「MinGW/MSYS をインストールする」を参考に MinGW/MSYS のインストールを完了させてください。 pgpdump の機能をフルに使うには zlib および bzip2 ライブラリも必要です。 これらのライブラリの導入についても 「MinGW/MSYS をインストールする」で紹介していますので参考にしてください。

次に pgpdump のサイトからソースコード一式をダウンロードしホームディレクトリ上に展開し， 以下の手順でビルドします。

$ cd ~/pgpdump-0.24/
$ ./configure
$ make
$ strip pgpdump.exe

あとは pgpdump.exe をパスの通ったフォルダにコピーすれば完了です。

現時点の最新版（0.24）は新しい DSA と SHA-224 に対応していません。 また ElGamal 暗号（Pub 20: 暗号および署名用）は既に Reserved になっていますが， これも有効なままです。 これらを修正したパッチファイル pgpdump-0.24.diff を用意してみました。 このパッチを適用した上でビルドするには先ほどの手順を以下のように変えます。 （パッチファイルはあらかじめ pgpdump-0.24/ ディレクトリにコピーしておきます）

$ cd ~/pgpdump-0.24/
$ patch < pgpdump-0.24.diff
$ ./configure
$ make
$ strip pgpdump.exe

オリジナルのソースコードとパッチファイルとビルド結果（Win32 バイナリ）をセットにして 以下のページに置いています。 是非ご利用ください。

• pgpdump (patched version)

（10/8 追記）

pgpdump 0.25 がリリースされました。 2440bis draft 18 の内容が反映され， hash 11 (SHA224) と s2k 2 (Reserved) の表示が出るようになっています。 DSA の表示については 0.24 と変わらないようです。 pgpdump のサイトからソースコード一式をダウンロードしホームディレクトリ上に展開し， 以下の手順でビルドします。

$ cd ~/pgpdump-0.25/
$ ./configure
$ make
$ strip pgpdump.exe

Win32 上でビルドしたものを 「pgpdump (patched version)」 に置いています。 ご利用の際は自己責任でお願いします。

「凄く美味しい家庭料理」みたいなお店があるというので連れてってもらいました。 実は「写真をとるのでつきあって」ということで行ったのですが。 （写真は後ほど）

「はしむら」のマスタは昔「広島アンデルセン」で修行されていたそうで， 特に卵料理が絶品です。 店内は落ち着いた感じでゆっくりお食事できそうです。 お酒も色々置いていますが， 特に焼酎と日本酒はかなりの種類を置いています。

下町料理 はしむら

広島県広島市中区新天地 1-24 壱番館ビル5F （地図）
電話 082-542-6246
ゆったりくつろげる家庭的なお店です。

写真もいくつかとりました。 あまり食事の写真をとることはしないのですが， 今回は頼まれちゃったので。 目の前に料理があるのにすぐに箸をつけられないなんて， まるでおあずけをくらっている犬のような心境でした。 撮った写真は Flickr で公開していますが， 今回は数が多いので一部だけ紹介します。

]]>

オムレツは何種類かあるのですが， これはチーズ入りオムレツ。 フワフワでとても美味しかったです。 外のネオン光で色味がちょっと変ですがご勘弁を。

ビールもあります。 これはスペインのビール。 味があって美味しかったです。

明太子入り卵焼き。 これが本当に美味しかったんですよ。 卵の食感と明太子の食感がまったく違和感なくて， 最初は卵焼きを食べているのにいつの間にか口の中が明太子になっている感じ。 このときはちょっと日本酒が飲みたかったです。 でもビールとも合います。

店内はこんな感じ。 焼酎がずらっと並んでいます。 奥にもいっぱいあるそうです。 日本酒は冷蔵保存が必要ですしね。

記事内のリンクからトラックバック情報を読み取って自動でトラックバックを送る設定にしている場合はトラックバックが上手くいかなくなる副作用がありますが， うちの場合トラックバックもそう多くないし問題ないかなと。 実際には spam はほぼ 100% プラグインが弾いてくれているのですが， 表示されないだけでデータベース内には残ってしまうので 定期的にチェックしてデータベースから削除する作業が鬱陶しいのですよ。 気が付いたら1,000件くらい溜まってることもありますし。

今回の措置でどのくらい効果があるか様子を見ていきたいと思います。

暗号アルゴリズムの危殆化（compromise）要因には色々あるのですが， 大まかに以下の3つに集約できると思います。 （「将来の暗号技術に関する安全性要件調査」より引用）

1. 暗号アルゴリズムの脆弱性（設計上の瑕疵など）
2. 攻撃法の進歩（既存攻撃法の改良、新たな攻撃法の開発）
3. 計算機性能の向上（解読計算能力の増大）

例えば前回紹介した SHA-1 への攻略法は上記の1番目の要因に相当します。 もし1番目および2番目の要因がないとするなら， 3番目の要因を取り除くためには鍵のビット長を大きくすればいいことに気がつきます。 鍵のビット長を大きくすればそれだけ試行回数が増えるため解読に時間がかかることになるからです。

解読に時間がかかるといっても無限の時間をかければいつかは解読できるわけで， そうなるとどれだけの時間をかければ安全といえるのかということになります。 「将来の暗号技術に関する安全性要件調査」 では「1年間の解読計算によって解読される確率が0.1％未満である」ことを以って安全としているようです。 これは言い換えると「解読計算を1000年間行っても，鍵空間が探索し尽くせない」ことを意味します。

また解読計算を行うには膨大な計算リソースが必要になります。 今後ともムーアの法則（「計算機性能は同一コストで18ヶ月で2倍になる」という法則）が成り立つとしても予算は有限ですので， 調達コストやランニングコストを考えれば計算速度にも上限が存在することになります。 この場合， 予算をどのように見積もるかが鍵になりますが， 「将来の暗号技術に関する安全性要件調査」 では以下の4つのケースを想定しています。

なお， 計算機性能の向上には物理的な限界があると考えられていますが（つまりいつかはムーアの法則は破られる）， その限界点についての議論も行われているようです。 それによると， クロック速度の相対論的限界はあと10の9乗（ビット換算で30ビット）程度， 集積度の量子論的限界もあと10の9乗（ビット換算で30ビット）程度， エネルギー面からも1年間の太陽エネルギーを用いて187ビットの鍵空間を探索するのが限界だそうです。 もちろんこれは現在のコンピュータの延長として考えた場合の話で， 例えば量子コンピュータが実用化されるなど画期的な技術革新があれば崩れてしまいます。 まぁその場合にはそもそも鍵長による安全性云々という話も成り立たなくなる可能性もありますが。

このように様々な条件を考慮した上で安全な鍵長の下限はどのくらいになるのか調べていきます。 ここでは調べる対象となる暗号アルゴリズムが以下の条件を満たしていると仮定します。

• 共通鍵暗号
• 全数探索（総当り法）よりも効率的な解読法が存在しない
• 有意性検定のコストは無視できることとする

これら条件を満たした上で予測される安全な鍵長の下限を以下に挙げます。 （全部は多いので一部だけ）

この予測によれは， 今後10年に限れば128ビット程度の鍵長で十分ということになります。

ところで， 日本国外ではどのような評価をしているでしょうか。 軽く調べてみましたが， これが結構あります。 代表的なものを以下にいくつか挙げてみます。

• ECC, Future Resiliency and High Security Systems （PDF）
• A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths
• RFC3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys
• ECRYPT Yearly Report on Algorithms and Keysizes (2005) （PDF）
• NIST Special Publication 800-57: Recommendation for Key Management - Part 1: General (Revised) （PDF）

特に欧州の ECRYPT （Network of Excellence in Cryptology）による年次報告は各方面の調査結果が並べられていてとても参考になります。 ここではひとつだけ NIST （National Institute of Standards and Technology） SP800-57 における評価結果を紹介したいと思います。

まず鍵の強度について共通鍵暗号と公開鍵暗号とを比較した一覧があります。

TDEA というのは TripleDES のことです。 DES はかつて共通鍵暗号の標準（FIPS PUB 46-3）でしたが， 標準の座を AES に明け渡して2005年に完全に廃止になりました。 ただし TripleDES については新たに SP800-67 を発行しその中で TDEA （Triple Data Encryption Algorithm）として規格化されています。

同じようにハッシュ関数についても一覧があります。

ハッシュ関数の場合， 目的によって要求される強度（ここではハッシュ値のビットサイズ）が異なるためこのような表になっています。 また前回述べたように， SHA-1 は予定の性能を下回ることが指摘されていて， 2010年までに SHA-2 （SHA-224, SHA-256, SHA-384, SHA-512）に移行するようにとの声明が出されました。

これらを踏まえて実際に安全な鍵長の下限がどの程度か挙げててみます。

先の IPA/ISEC の評価（こちらは2018年までしかないので簡単に比べられませんが）より若干緩い感じですね。 現状では AES-128 よりも強い暗号は必要なさそうです。 共通鍵暗号に関しては他も大体同じような結果になっていますが（ECRYPT の報告は少し厳しいですが）， 公開鍵暗号に関しては報告書によってばらつきが大きいため参考程度に留めておくのがいいかもしれません。 パッと見の印象では今回紹介した NIST の報告がバランスが取れていて妥当なところではないでしょうか。

以上で署名・暗号に使う鍵の長さについて大体イメージできたのではないでしょうか。 最初に述べたように暗号の危殆化には様々な要因があり， 「鍵長を大きくしたから安心」というようなものでもありません。 暗号技術を含むシステムを開発・運用している方々は常に技術の最新動向に注意しておく必要があります。 この記事が何らかの手助けになれば幸いです。

参考：

• 暗号の危殆化に関する調査
• CRYPTREC Report 2005の公開 （5月に改訂版がリリース）
• デファクトスタンダード暗号技術の大移行 第5回 鍵長をどのように選択していくか～等価安全性と鍵長の関係