コードサイズの最適化とは？最新の暗号化について紹介

コードサイズの最適化とは？最新の暗号化について紹介

2019年6月8日から9日にかけて、アムステルダムでBreaking Bitcoinというカンファレンスが行われました。本コラムは、公開された動画や書きおこしをもとに、その発表内容を追いかけ、Bitcoinのセキュリティに関する取り組みの最先端を知ろうという試みです。

発表内容を日本語で、かつ実際の事例などを交えて解説することで、少しでも皆様がBitcoinの仕組みや最新の研究について詳しくなるための一助になれることを願います。
今回はJonas Schnelli氏の”Bitcoin P2P Encryption“という講演を取り上げます。

ビットコインの改善の提案、BIP324とは

Bitcoinでは、改善の提案をBitcoin Improvement Proposals（BIP）として受け付けています。Jonas Schnelli氏の提案は、BIP324として提案される見込みで、バージョン2（v2）のメッセージ転送プトロコルと呼ばれています。

このメッセージ転送プロトコルは、コンセンサスを変更するものではなく、純粋にP2Pネットワークレイヤーの変更を意図しています。バージョン2でどのような改善が見込めるのか、詳しく見ていきましょう。

古い提案BIP151とはどう違うか

ゴールは日和見暗号（Opportunistic Encryption）を実装することです。提案は暗号化と認証に分かれているため、新しい認証スキームが実現できます。

BIP324の詳細は現時点でまだ確認できませんが、筆者が理解する限り、ノード間でやりとりするメッセージのフォーマット、つまりブロックに手を入れることで、通信量を削減したり、暗号化の処理量を減らすことを意図しています。

例えば現在の実装（v1と呼んでいます）では、4バイトのマジックヘッダ、12バイトのメッセージコマンド、4バイトの長さ、4バイトのSHA256チェックサムであり、パケット全体は少なくとも24バイトとなります。チェックサムはペイロードのハッシュで、4バイトに切り詰めています。しかし、これには無駄な部分があります。

まず、インベントリメッセージ（inv）は12バイトから1バイトにすることができます。そして、v2では長さを3バイト、メッセージやペイロードは可変長、16バイトのMACを加えて最小20バイトとします。最大のサイズは8MBですが、これを超える場合は、もちろん分割も可能です。

BIP151は数年前に提案されましたが、ほとんどの実装は遅いと言い切れるもので、以降は改善も行われていません。骨董品と言ってもいいでしょう。データから生成されたトランザクションを、もちろん丸ごと公開したくはありません。Bitcoinネットワークは監視されていると言ってよいでしょうから、認証つきの暗号化はネットワーク上で必要なものです。

そこで、ブロック生成を変えます。ユーザーにとっても利益のある変更です。

暗号とハンドシェイク

繰り返しますが、暗号の再発明や追加ではなく、ブロックに関する変更です。したがって、暗号化といったときには、TLS1.3やTorといった既存のツールが前提になります。

Bitcoin署名と同じsecp256k1曲線、Diffie-Hellman鍵交換、ChaCha20暗号、Poly1305によるMACメッセージ認証コード生成を行います。また、秘密情報をハッシュ化するHKDFという構造を使います。これはRFCで標準化されています。

ここで大切なのは、依存関係や情報量を減らすことです。

次にハンドシェイクについて。

ノード間で接続する場合、バージョン番号を送信せず、代わりに32バイトの公開鍵を送ります。他に何も送らず、本当にそれだけを送ります。
ノードは応答された情報を読み取り、まず、互換性のために用意されたv1用のヘッダーと一致するか確認します。これにより、後方互換性が保たれます。

公開鍵とわかった場合はDiffie-Hellman鍵交換で公開鍵を送り返します。これでハンドシェイクが完了します。32バイトという点は、他の通信がきたときに33バイト目で判断できるなどの利点があります。こういった性質でセキュリティが低下することはありません。

認証、そして改善

Peter Dott氏は、BIP151の議論で「中間者攻撃を検出でき、優れた防御を提供します。攻撃を検出し、行動を変えることができます」と述べました。しかし、みなさんがご存知のように、HTTPSなどのSSL接続は認証局に依存しています。いくつかの企業にリストがあり、証明書とキーが存在しています。

しかし、この集中化された方式はBitcoinが見習いたいものではありません。また、SSHを日常的に使うようなエンジニアであれば、サーバーのフィンガープリントを取得して確認するプロセスは見たことがあるでしょう。これは、最初の一回で攻撃された場合は防げないものの、一度接続したあとで中間者攻撃が発生した場合、それを検知するための機能です。

しかし、Bitcoinは同じようにはいきません。こういった認証は範囲外とし、別の良い提案を待つべきでしょう。

v2の考え方は、半年ごとに新しくBIPをメンテナンスするのではなく、一連のメッセージをこれ以上ない形にしたいということです。実際、パフォーマンスの観点ではv2の方が優れています。最適化済みのsha256と最適化されていないChaCha20を比較したとき、小さなメッセージではChaCha20が非常に高速です。

INVやping/pong（到達性の確認）のように小さなサイズのやりとりが多いので、メッセージサイズにあわせて最適化することで、より素晴らしい効果が得られるでしょう。

まとめ

以上、Jonas Schnelli氏の”Bitcoin P2P Encryption”という講演をまとめさせていただきました。記事中の表現については講演資料を筆者なりに読み解いた上で独自の解説を加えておりますが、なにぶん新しい技術に関する内容ですので、もしも間違いなどございましたらお気軽にご指摘くださいませ。（特に技術的な指摘は大歓迎です）

次回は、Kalle Alm氏のMempool Analysis and Simulationという講演を取り上げてみたいと思います。

Source: 仮想通貨ニュースサイト
コードサイズの最適化とは？最新の暗号化について紹介