あけましておめでとうござます。 ウェブ関連技術の標準化を進めているW3Cから W3C Web Cryptography API という勧告候補が 出てまして、このAPIを使えば公開鍵暗号、共通鍵暗号、鍵交換、鍵生成、 暗号化、署名、ハッシュ関数、擬似乱数なんかが使えちゃうのだそう。 Twitterの私のリプライに「ほとんどのブラウザがサポートしてるから (jsrsasignでも) 使いなさいよ」と海外から何名かの方がコメントしてくださるので、 重い腰を上げて勉強してみたんですが、「ムキ〜〜っ！！わけわからん！ 標準化って何なの？相互運用性著しく低いしっ。そもそも、 このAPIってJavaScriptを書くプログラマにちっとも優しくないよね！」 と怒り心頭なんですが、 年も明けたことですし、そのあたりのことを愚痴っぽく、 ぼちぼち書いてみたいと思います。
結論から言うと「今すぐ、これを使うとヤケドするので、 実装がこなれてきたり、様々なラッパーやユーティリティが整備される まで使うのは1、2年はお待ちなさい」という事かなと思います。
APIはどれくらい使えるの？
いろいろなウェブブラウザの機能のサポート状況を 公開してくれているサイトにcaniuse.comという サイトがあるのですが、そこで W3C Web Cryptography API の主要なウェブブラウザ毎のサポート状況 が公開されています。
(出典：
Can I Use Web Cryptography)
グレーで囲まれているのが2015年1月時点で現行バージョンのブラウザで、
緑はフルサポート、黄緑は一部サポートを示しているんですが、
IE、Firefox、Chrome、Safari、Operaやスマホなどのほとんどブラウザで
APIをサポートしていると言っています。
世界のブラウザシェアでは51.39%、日本では58.17%が
APIをサポートしているのだそうです。
この図だけを見たら、問題なく簡単に使えそうな気がしちゃいますよね。
ハッシュ関数の例
それでは早速、ハッシュ関数の例を見ていきましょう。 文字列"aaa"のSHA-1ハッシュ値を計算するとします。 細かい関数は後で紹介していくとして、ハッシュ計算の流れは以下の例の ようになります。
APIのハッシュ関数、暗号化、鍵生成などの関数は、乱数生成を除いて 全て "window.crypto.subtle" の名前空間に入っており、 ハッシュ関数は "digest" となっています。var textBuf = asciitouint8a("aaa"); // ハッシュ対象文字列aaaをUint8Arrayに変換 window.crypto.subtle.digest({name: 'SHA-1'}, textBuf).then( // SHA1ハッシュを計算 function(hashValue) { // 成功した場合に呼び出される関数 console.log("sha1(aaa)=" + abtohex(hashValue)); // 結果ArrayBufferを16進数に }, function(error) { // 失敗した場合に呼び出される関数 console.log("sha1(aaa)エラー: " + error); } ); #文末にasciitouint8a, abtohexのコードはつけておきます。
ハッシュの入力はHTML5で導入されたバイナリデータを扱うクラスUint8Arrayなど、 ハッシュの結果はArrayBufferクラスで帰ってきます。例では文字列から Uint8Array配列にしたり、ArrayBufferを16進数で表示できるようにユーティリティー関数を 使っています。
APIの殆ど全ての暗号機能は非同期実行APIになっており、 関数やメソッドが実行されても、すぐには結果が帰ってきません。 ウェブブラウザで、ある処理を行っている間、表示が固まったりしないように 非同期実行にしてあるのだそうです。(後日、突っ込みますw)
JavaScriptで非同期実行するには2通りの方法があるらしく、 windows.crypto.subtle.digest関数は非同期実行オブジェクトを返します。
- Promiseパターンを使う方法(thenを使う。WebCryptでは主流?)
- イベント(oncomplete,onerror)を使う方法(IE WebCryptで主流?)
Promiseパターンによる非同期実行
Promiseパターン、もしくはDeferredパターンと呼ばるデザインパターンは、 非同期処理は遅延実行を扱うパターンなのだそうです。 上の例ではdigest()関数により、非同期実行のためのPromiseオブジェクトが 生成され、処理が終わった際にどんな関数を実行するか、エラーが起きた際に どんな関数を実行するかをthen()メソッドで定義しておきます。
Promiseパターンでは、非同期処理するオブジェクトをthenでチェーンすることにより、 処理1、処理2・・・のようにシーケンシャルに実行させることも可能です。var promiseObj = new Promise(); promiseObj.then( 処理が終わった時に実行される関数, エラー発生時に実行される関数 );
Promiseパターンの方が、後述のイベントによる非同期実行よりも、 thenチェーンなど使えて綺麗に書けるので Web Crypto APIでは、 こちらの方が主流の使い方となるのだと思います。 Promiseパターンについて詳しく知りたい場合には、以下を参考に されると良いと思います。var promiseObj1 = new Promise(); promiseObj1 .then( function(result) { // 処理1が成功したら実行される関数 ... return new Promise(); // 新しい処理2の非同期処理オブジェクト } function(err) {...} ).then( function(result) { // 処理2が成功したら実行される関数 ... return new Promise(); // 新しい処理3の非同期処理オブジェクト } function(err) {...} ).then( // 処理3 );
イベントによる非同期実行
IEのWeb Crypto APIのサンプルでは、digest()で非同期実行オブジェクトを 生成するところまでは一緒ですが、これに処理が完了した場合に実行される 関数を参照するイベントプロパティ oncomplete と、エラーが発生した際に 実行される関数を参照するイベントプロパティ onerror を定義することにより ハッシュ計算を非同期実行しています。
IE 11+のW3C Web Cryptography APIでは、Promiseパターンではなく、 イベントによる方法しかサポートされていないのだと思います。var data = new Uint8Array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); var digestValue; var crypto = window.msCrypto; if (crypto.subtle) { var op = crypto.subtle.digest({ name: "SHA-256" }, data); op.onerror = function (evt) { console.log("op.onerror event handler fired."); } op.oncomplete = function (evt) { digestValue = evt.target.result; console.log("op.oncomplete event handler fired, digest computation complete."); }; } else { console.log("Unable to create window.crypto object."); } (出典：MSDN: Web Cryptography: digest method)
Web Crypto APIの困った所1：非同期実行
ここから、なんだか愚痴や文句っぽくなってきますorz
W3C Web Cryptography APIの困ったなぁと思うのは、
(処理が大して重くないのに)非同期実行しかサポートされていないところです。
非同期実行は、それを使い始めてしまうと以降の全ての処理を非同期実行
しなければならず、途中の一部だけを非同期実行することができません。
非同期実行は鍵生成して、鍵を保管して、署名するといった一連の処理を まとめて非同期実行させて、表示が固まらないようにしたいのであり、 個々の暗号プリミティブレベルで非同期実行したいわけではないと思います。 暗号プリミティブを非同期実行するかはプログラマに任せてほしく、 暗号プリミティブは同期実行の方がよかったのではないかと思います。
IEと他のブラウザとで非同期実行の記述に一貫性が無いのも面倒だと思います。
Web Crypto APIの困った所2：名前空間が統一されてない
Can I useサイトやMSDNの例を見て「あれ？」と思った人もいると 思いますが、Web Crypto APIの名前空間って実装によって統一されている というわけではないんです。
- window.crypto.subtle - Firefox、Chromeなど
- window.msCrypt.subtle - IE11+
- window.crypto.webkitSubtle - Safari, iOS Safari
Web Crypto APIの困った所3：ArrayBufferによるインタフェース
ハッシュや署名の入力はUint8ArrayといったArrayBufferViewのサブクラスでなければ いけなかったり、出力はArrayBufferになっていたりと、 文末のasciitouint8aやabtohexなど見てもらえれば判る通り、 処理するのが結構面倒くさいです。 ファイルなど大きなサイズのデータを扱う際にはわかりますが、 ハッシュの結果となるハッシュ値なんか大した大きさでないのに ArrayBufferで戻されます。
Web Crypto APIの困った所4：多態性のなさ
ハッシュ関数の入力に関して、文字列でも、整数は配列でも、Uint8Arrayでも 「ひとつよしなに」ハッシュを計算してくれてもよさそうなもんですが、 そうした 多態性(polymorphism)は無くて、 入力はUint8ArrayのようなArrayBufferViewでなければなりません。 多態性はJavaScriptの大きなメリットの一つだと思うんですが、 W3C Web Cryptography APIを使っていると、JavaScriptから Cで関数を呼び出ししているような気分になります。 (入力の融通のきかなさは次回他にも紹介します。)
Web Crypto APIの困った所5：ドキュメントやサンプルの少なさ
解説記事やサンプルを紹介しているサイトもあるのですが、そもそも、例が少ないですし、 それが希望のブラウザで動作するかわからず、コードの相互運用性に本当に苦労させられます。 また、ブラウザがどの機能をちゃんとサポートしているのか、よくわからず、公開ドキュメントも ないので、それが自分のコードのバグなのか仕様なのかよくわからない事も問題です。
おわりに
というわけで、今回は導入として、W3C Web Cryptography APIの雰囲気とハッシュ関数の例に ついて見てみました。 不勉強なため、認識違いをしている所もあると思いますが、その際にはコメント等でご指摘いただければ と思います。 次回以降、鍵生成、署名、共通鍵暗号等を紹介したり、 勉強になるサイトを紹介していこうと思います。 ではでは。
関連記事
- W3C Web Cryptography APIとの果てしなき戦い(第3回 動くサンプル1)(2015.01.19)
- W3C Web Cryptography APIとの果てしなき戦い(第2回 RSA署名生成と検証)(2015.01.05)
- W3C Web Cryptography APIとの果てしなき戦い(第1回)(2015.01.02)
- ロシアの方が開発したJavaScript PKIライブラリPKI.jsをさわってみたぞ(2014.05.10)
(おまけ)例で使ったabtohex、asciitouint8aの定義
// ASCII文字列をUint8Arrayの配列に変換 function asciitouint8a(s) { var buf = new Uint8Array(s.length); for (var i = 0; i < s.length; i++) { buf[i] = s.charCodeAt(i); } return buf; } // ArrayBufferから16進数文字列に変換 function abtohex(arrayBuffer) { var s = ""; var dataView = new DataView(arrayBuffer); for (var i = 0; i < arrayBuffer.byteLength; i++) { var hex = dataView.getUint8(i).toString(16); hex = "00".substr(0, 2 - hex.length) + hex; s += hex; } return s; }
