2017.07.27

IPv6のアクセスが20%に達する

前回の記事では、IPv6でのGoogleへのアクセスが全体に対し2015/12/31に10%に達したと述べたが、同じサイトで 2017/7/22 に 20.10% に達したことがわかった。

5%から10%は15ヶ月かかっていたが、10%から20%は19ヶ月かかったことになる。2016年12月のInternet Watchでの予想では、「2019年に50%を超える」とのことである (このペースではちょっと厳しいか?)。

以前はIPv6には「キラーアプリケーションがない」と言われることもあったが、IPv6とIPv4の両方で同じサービスが受けられることを前提にしている今のやり方では、IPv6のみでアクセスできるアプリケーションなどあるはずがない (あってはいけない)。私は、IPv6の普及には、IPv6のほうが安い・高速・安定しているといった接続環境としての差別化が必要になると考えている。

土日に比率が高くなる傾向は以前から続いているが、最近は金曜日から比率が高まる状況にある。これはインドでの普及率の上昇 (と、その背景にあるIPv4アドレスの枯渇) が原因にあるのかもしれない。モバイル環境からのIPv4のアクセスがNAT経由になると、IPv6のほうがコスト的にも速度的にも有利になる。その時、意外と急速にIPv6への移行が起こるのかもしれない。

2017.02.24

SHA-1の強衝突耐性が破られた

Internet Watchによれば「GoogleとCWI、SHA-1衝突に成功……」とのことである。

Freestart Collisionが見つかってから、1年4ヵ月くらい。MD5の8年に比べるとかなり早い。ただし、元記事によると相当な計算をクラウド上で行っている模様 (単純なブルートフォース攻撃ではない)。

MD5でコリジョンが発見されたケースに比べれば影響は低い (というか、既に予想されていた) と思われる。すでに主要なブラウザではSHA-1の証明書は無効化されているか、無効化される予定になっている。MD5の場合はコリジョンが発見されてから無効化されるまで8年くらいかかっている。しかし、SHA-1も本当に破られましたね (以前のネタ)。

2016.01.04

IPv6のアクセスが10%に達する

Googleに対するアクセスの比率では、IPv6が (全体に対して) 2015年12月31日に10% に達した (1日あたり) らしい。アクセスは休日に高くなる傾向があり、スマートフォンなどの携帯デバイスが (米国で?) IPv6 を使用しているのがその原因らしい。年末のホリデーシーズンにアクセスの比率が高くなり、10%の大台に達したところである。

これは、10%のホストがIPv4を使用できないことを意味しているのではなく、10%のホストがネットワーク環境を含めて、(おそらく) IPv4とIPv6の両方を使用できることを意味している。現状ではIPv4でのアクセスしかできないサーバがあるため、IPv6のみのホストはほとんどないと考えられるからである。

5%を超えたのが2014年10月なので、15ヵ月で倍増したことになる。上限を100%としてロジスティック曲線にあてはめようとしたが、精度が出なかった。上限を20%とするとかなりの精度で実測値と一致する。これはIPv6のアクセスが20%を超えないことを意味するのか……ゴンペルツ曲線にあてはめると、上限が50%程度で比較的近い値になった。いずれにしても、現時点での未来予測は困難のようである。

2015.10.13

SHA-1の「Freestart Collision」が見つかる

SHA-1の「Freestart Collision」が発見されたとのことである。

Freestart Collision (フリースタート衝突?) というのは、本来は規定されている初期ベクタ (IV) の値を都合の良い値に変更した上でSHA-1の全手順を実行させた場合に発生する Collision のことである (詳しい解説が、ここにある)。

SHA-1 は規定された80ラウンドから縮小したアルゴリズム (本来のSHA-1とは異なる) では既に Collision が見つかっていたが、80ラウンドを全て備えたアルゴリズム (ただし、IVが異なるため本来のSHA-1とは異なる) では初めてらしい。

これによって、SHA-1を使用した証明書の偽造がすぐにできるようになるとかいう話もでているようだが良く解らない。ちなみに、MD5の場合にはFreestart Collisionが見つかってから、本物のCollisionが見つかるまでに8年かかっているらしい (いずれにしても、既にNISTによりSHA-1は非推奨とされており、早急にSHA-2への移行を進めるべきである)。

2014.02.06

紀元前の日付の表記法

今まで50年以上(?)なんの疑問も持たずに生きてきたのであるが、紀元前の「日付」は何暦に基づいて表記されるのか、疑問に思った。

Wikipediaによると、ユリウス暦が制定されたのは紀元前45年(安定して運用されたのは紀元8年以降)らしい。紀元前45年以降はユリウス暦による表示が可能(ただし、運用は複雑)という事らしい。紀元前45年より前という事になるとローマ歴が存在した事になるが、運用はさらに恣意的であったという事である。

実際に紀元前の日付が使われている個所を具体的に見てみると、紀元前100年7月13日にユリウス・カエサルが誕生したとある(異説あり)。紀元前100年の記事では「日付はユリウス暦」とあるが根拠は述べられていない。当人の記事本文からすると「ローマ歴」の方が正しいようである。

ローマ以外を調べると、漢の武帝が即位したのが紀元前141年3月9日という事である。紀元前141年はローマ歴の時代であるが、日付は中国の暦(顓頊暦)らしい(対応するローマ歴の日付が求められるかは不明)。ちなみに顓頊暦は太陽年の長さが365.25日でローマ歴よりも精度が高い。

さらに古い記述を見ると、紀元前763年6月15日に日食を記録したとの記載がある(この日付は日食の起こった時間を天文学的に推定したものらしい)。紀元前763年であればユリウス暦はもちろん、ローマすら建国されていない。暦法はおそらくユリウス暦の規則をそのまま遡ったものか、あるいは、グレゴリオ暦を遡ったものと思われるが明記されていなかった。

常識がないので歴史上どのように表記するのが標準なのか良くわからない。まったく勘が働かないので土地勘のあるコンピュータでの規格で見てみる事に方針転換を図る事にする。

土地勘があるところということで、Javaのjava.util.GregorianCalendarでは、1582年10月4日まではユリウス暦、10月15日以降がグレゴリオ暦という事である(設定により変更可能)。

GregorianCalendar は、「予期的」グレゴリオ暦およびユリウス暦を実装します。すなわち、日付の計算では、現在の規則を無限の過去あるいは未来に向けて適用します。このため、GregorianCalendar はすべての年について一貫した結果を生成するために使用できます。ただし、GregorianCalendar を使用して得られた日付は、歴史的に、現代と同様のユリウス暦が採用された AD 4 年 3 月 1 日以降の日付だけが正確です。この日付より前には、うるう年の規則は不規則に適用されており、BC 45 年以前にはユリウス暦は存在さえしていませんでした。
の注意書きがある。したがって、紀元前の日付はユリウス暦の規則をそのまま遡る方式である(設定により純粋なグレゴリオ歴とする事も可能)。

日付の表記法の国際規格であるISO8601では、

ISO 8601 では日付の表記にグレゴリオ暦を用いることになっているので、ユリウス暦の用いられていた時代の日付を表す際にはグレゴリオ暦に換算する必要がある。
という事なので、紀元前の日付は(紀元前でなくてもだが)グレゴリオ暦の規則をそのまま遡る方式である。ちなみに年の表示は紀元前1年が0000、紀元前2年が-0001となる。

あえて結論を言うとすれば、西暦の基本となるユリウス暦やグレゴリオ暦は紀元前には存在しないか、存在しても今と同じ運用はされていなかったという事であり、紀元前の日付は文脈依存にならざるを得ない。日付を書く場合にはどの暦法による日付かを明記すべきという事になるであろう。

2013.09.17

環境依存文字(Unicode) 一覧

拙稿「Unicode固有文字とUnicode依存文字」に対し「環境依存文字 Unicode 一覧」のような検索ワードでたどり着いて閲覧している方がたまにおられる。すでに書いたように「『表せない文字』を定義するのは無理があるため、表せる文字の方を定義すべきである」のだが、どうしても一覧が欲しい向きもありそうなので情報のリンクを示しておく。

Windows Vista ならびに Windows Server 2008 における JIS2004 対応に関する詳細資料」という情報である。マイクロソフトが公式に示したWindows Vista以降に追加した文字の情報である。追加された文字は、ある意味「シフトJISで表せない文字」であるし、一覧でもあるので「環境依存文字(Unicode)」の一覧と言えなくもない。

もちろん、「環境依存文字(Unicode)」はユーザ定義(単語の登録)でいくらでも追加できるので、上記の一覧では不完全であることは言うまでもない(完全な一覧は最新のUnicodeの規格を参照する以外にない)。

2012.02.06

東アジアのサイトは奇数年に増える?

Googleによれば、Unicodeを使用したサイトが60%を超えたとのこと。

その事自体は別に驚きは無い。既に50%近いという報告がなされていて、別に遅いとも早いとも思わなかった。ただし、グラフを見ていて不思議な感覚を持った。

なぜ、JapaneseやChineseは奇数年が多いのだろう……

Chineseについては2006年以降で一貫してこの傾向が見られる。Japaneseは2010年以降だが、やはり同じ傾向である。よく見ると、ASCIIも2008年以降同じ傾向がある。Latin-1は逆に2007年以降奇数年に少ない傾向がある(その結果、1年置きにASCIIと2位が入れ替わっている)。件のUTF-8も2008年以降同じ傾向である。

いったい、なんでこんなことになっているのでしょう……

2011.10.23

Unicode固有文字とUnicode依存文字

最近、Webを見ていて、「Unicode固有文字」という用語が使われている場合がある事に気がついた。世界中にはUnicodeでしか文字コードとして表現できない文字(楔形文字など?)は存在するが、日本で使われている文字の大半はUnicodeに収録される以前から他のコード(Adobe-Japan1-6など)に収録されているので、Unicodeに「固有」であるという事はまずない。

「固有」は変という事からか、「Unicode依存文字」という言い方もあるようだ(これは、MS IMEの「環境依存文字 (unicode)」という表現から派生したのかもしれない)。しかし、先に述べたようにUnicodeに「依存」しない表記はほとんどの場合可能である。内部処理でUnicodeに依存しているのだと言うのであれば、WindowsにしてもMacintoshにしても現在では全ての文字がUnicocdeに依存している状態である。そもそもHTMLの規格レベルでUnicode(厳密にはUCS)に依存しているのであるから、Web上の文字は全てUnicode依存と言っても差し支えない。

という訳で、Unicocde固有(ないし、Unicode依存)文字の意味は自明ではない。定義が必要だが、意味が述べられているところでは「(シフト)JISに存在しない」文字が多かった(少数だが「EUCに存在しない文字」というのもあった)。しかし、シフトJISとはなんぞやというのは意外と難しい。そもそもJISと言ってもJIS X 0208なのか0213なのか不明である。シフトJISからは IANAの "Shift_JIS" を連想する(Shift_JISはJIS X 0208ベースである)が、シフトJISと言った場合はWindows-31jの事を意味している場合の方が多いであろう。EUCも複数あるが、IANAの "EUC-JP" であれば、JIS X 0208とJIS X 0212がベースである。

抽象的で良く解らないと思われるため、例として、以下の文字を含むか否かを考える。

  • 丸数字「①」
  • 森鷗外の「鷗」
  • 內田百閒の「閒」
  • アクセント符号付きのアルファベット「À」

Unicode固有文字の明確な定義がある訳ではないので、上記の文字に対して一貫した答えは出ない。JIS X 0208ベースであれば上記の文字は全て「Unicode固有」となる*1であろう。Windows-31jであれば、「鷗」と「À」だけが「Unicode固有」となるであろうし、EUC-JPであれば「①」と「閒」だけになるであろう。結局のところ、単に特定の実装(処理系)で表せない文字を「Unicode固有」等の言葉で表現しているものと思われる。「表せない文字」を定義するのは無理があるため、表せる文字の方を定義すべきである。

--------
*1: 厳密には包摂しているため表現可能な文字も存在するが、字体を区別する事はできない。

2010.09.15

田中舘博士のタイプライタ

昨年の9月に岩手県二戸市にある田中舘愛橘記念科学館に行ってきた。そこに展示されていたのが写真のタイプライタである。一見して通常のQWERTY配列ではない事が解る。かといって、Dvorak配列でもない。調べてみたところ、これは日本式コロナと呼ばれているタイプライタの配列である事が解った(田中館愛橘・タイプライタ・日本文化)。

P9210112

キー配列を以下に示す。(写真から読み取ったため誤りを含む可能性があります)

- L Y O U M N R B J X
, W I A E S T K H Q ^
. F Ô Û C Z D G P V

尚、上記の「田中館愛橘・タイプライタ・日本文化」に示された「日本式4段コロナ機の配列」と比べるとWとFが入れ替わっている事が解る。これは本文中の「それで、この "w" とその上のホーム段の "f" とを入れ換えてはどうかと考え、出張中ではあったが、さっそくパリでタイプライタをそのように改造してもらったら、確かに改良となった」の記述と関係があると思われる。

2009.01.07

MD5の脆弱性を用いた証明書の偽造

「MD5 の collision attack を使用して、X.509 証明書の偽造に成功したという研究発表」の報告があった。備忘録として知り得た情報を整理しておく。

今回の攻撃は既知のMD5の強衝突耐性への攻撃を用いており、MD5のハッシュ値の衝突を起こすように作られたX.509の証明書の例は過去にも報告されている。今回の新しい点は

  • 正規のCAの署名をつける事に成功した
  • サーバ証明書ではなく、中間証明書が得られた
の2点であろう(つまり、正規のCAの署名付きの中間証明書が得られた事になり、攻撃者は「正統なCA」に成り済ました状態になる)。これで攻撃者はどのような証明書も自由に作れる事になる(実際の方法は「自堕落な技術者の日記」に詳しい)。

もちろん、SHA-1で署名したサーバ証明書の作成も(必要なら新たな中間証明書の作成も)可能なので、証明書が今回の攻撃によって作られていない事を確認するためには(全ての)中間証明書の署名がMD5を用いていない事を確認しなければならない。また、ルート証明書は自己署名なのでどのようなアルゴリズムを用いているかは関係ない。

尚、今回の攻撃ではMD5の強衝突耐性が破られている(既存の攻撃と同じ)、弱衝突耐性が破られた訳ではない(任意の証明書が作れるのはCAの成り済ましに成功したからであってMD5の弱衝突耐性とは関係ない)。従って、既存のMD5を用いて署名された証明書が直接改竄できる訳ではない。もちろん、いまだにMD5を使用しているCAがある事自体が大問題な訳で、今回の発表は最後通牒と言えるだろう。

«正規等価(Javaの正規表現)

最近のトラックバック

無料ブログはココログ

Googleアナリティクス

  • Googleアナリティクス