暗号化済みファイルの生成処理の修正
Opened this issue · 3 comments
plugins/metalsmith/url-shortener/encrypt.jsに含まれるいくつかの問題を修正する。
-
authTagLengthを生成するバイナリファイルに含めないcipher.getAuthTag()メソッドが生成するBufferオブジェクトのlengthプロパティから取得できるため。TLS1.2のAES-GCMフレームにも含まれていないため、おそらく省略は可能。 -
crypto.createCipheriv()のauthTagLengthオプションを省略するGCM modeでは、
authTagLengthオプションは省略することができる。初期値は16 bytesで、これは現在の設定と同様。ただでさえややこしいのだから、省略できるパラメータは除くことが好ましい。追記：
aes-256-gcmではauthTagLengthオプションが省略可能だが、chacha20-poly1305ではauthTagLengthオプションが必須のため、省略はしない。 -
バイナリデータのチャンク長を表現する数値でunsigned-varintを使用する。
当初はPNGのチャンクと同様に同じ
chunkTypeを持つ複数のチャンクで255 bytesを超える長さのデータを扱うつもりだったが、WebAssemblyのunsigned LEB128やmultiformatsのunsigned varintのほうが効率が良いと思われるため、varintパッケージを使用して対応する。 -
ivの再生成で乱数のみを使用しない初期ベクトル（IV）の生成に乱数を用いた場合は、多量の暗号化処理の際に同じ乱数が生成され、衝突する可能性が高まる。誕生日パラドックスにより、この確率は意外と高い。この用途ではビルドの度に再生成するため、データ通信ほど高頻度に生成されることは無く、このリスクはおそらく無視できるほどに小さい。しかし、将来（私自身を含め）誰かがこのコードをパクってデータ通信処理を書いた場合に、脆弱性を組み込む可能性がある。
よって、
Date.now()の返り値を使用する。ECMAScript Date objectsがサポートする最大のUnixtimeは8,640,000,000,000,000ミリ秒で、これは7 bytesに収まるため、Unixtimeに追加の乱数5 bytes（もしくは6 bytes。Unixtimeの最大値も6 bytesになるが、6 bytesを超えるのは西暦10889年8月2日であるため、問題は無い）を追加した値を初期ベクトル（IV）に使用する。
よって、
Date.now()の返り値を使用する。ECMAScript Date objectsがサポートする最大のUnixtimeは8,640,000,000,000,000ミリ秒で、これは7 bytesに収まるため、Unixtimeに追加の乱数5 bytes（もしくは6 bytes。Unixtimeの最大値も6 bytesになるが、6 bytesを超えるのは西暦10889年8月2日であるため、問題は無い）を追加した値を初期ベクトル（IV）に使用する。
データ通信処理への転載を想定するなら、ミリ秒単位の日付情報なんて当てにならない。実装次第では1秒ごとに変化するなんてこともある。1秒の間に、6 bytesの乱数が誕生日パラドックスで衝突してしまうリスクは十分考慮すべきでは？
まっとうな実装は、IVとしてカウンターを使います。
─ 本当は怖いAES-GCMの話 - ぼちぼち日記
暗号化処理のオプションで以前までのカウント値を指定できるようにしたほうがいいぞ…
必須オプションにすれば、省略もできなくなるし、勉強になる
cipherivでnpm内を検索したら、以下の興味深いパッケージを発見した：
string-crypto
「1つのパスワードのみでデータを暗号化する」という目的は共通している。
ただし、IVをランダムに生成していたり、Bufferをわざわざ文字列化して結合していたりと問題もある。
興味深い点として、パスフレーズを鍵導出関数の一種PBKDF2を使用してハッシュ化した上でcrypto.createCipheriv()メソッドのkey引数に渡している。この点は考慮していなかったため、必要があれば導入を検討するべきかもしれない。@ronomon/crypto-async
Node.js組み込みのcryptoモジュールを高速化・マルチスレッド対応化したものらしい。
ところで随分前に@sounisi5011/encrypted-archiveを作ってしまってだな