2024年5月20日～2024年5月26日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第158回分。
[Cloudflare Radarで見るPQC]
こちらのツイートから。
Whoa! Post-Quantum for HTTPShttps://t.co/PRDz3mAgx6 pic.twitter.com/JyeOAuAdPW
— 🎻 Eric Lawrence (@ericlaw) 2024年5月21日
リンク先はこちら。
Cloudflare Radar: Post-Quantum Encryption Adoption
平日は20%近くまで耐量子暗号で暗号化されたトラフィックがある模様。4月末時点では、↓のブログにも書いた通り13%程度だった。1ヶ月でさらに利用が増えている模様。
耐量子暗号を利用したハイブリッド鍵交換は、デスクトップ版のChromeのみでデフォルト有効化されている。週末はみなさんモバイル中心になるんですかね...。モバイルChromeでもデフォルト有効化されると、さらに数値が跳ね上がる予感。
[その他のニュース]
▼[宣伝] TLS季報 vol.2
こちらのツイートから。
https://t.co/gRuJYzbY9i
— KIDANI Akito (@kdnakt) 2024年5月25日
というわけで出ました🙇
ご笑覧ください。#技術書典
リンク先はこちら。
どうぞよろしくおねがいします🙇
vol.1も合わせてどうぞ。
▼JA3は何の略？
こちらのツイートから。
There's an interesting method for creating SSL/TLS client fingerprints called JA3, and I've always wondered what the name stands for. This was a bit unexpected 😅
— Michal Špaček (@spazef0rze) 2024年5月20日
And now I've discovered there's JA4+ so naturally I went to check what that stands for ...
Who says naming is hard pic.twitter.com/dc9poRggeN
TLSクライアントの接続パラメータなどをもとにフィンガープリント（指紋）を作成し、クライアントを識別するJA3という技術がある。名前の由来は開発者3人のイニシャルがすべてJAだから、ということらしい。そうだったのか...。
JA3はAWSでもWAFで利用可能である。
同じメンバーで開発された、JA4+というより汎用的なネットワークフィンガープリントの技術もあるとのこと。
▼BGJ15 revisited：Kyber-512は安全か？
こちらのツイートから。
18 months ago NIST suddenly switched to counting memory-access costs in lattice attacks, massively pumping up Kyber-512's claimed security level. New lattice-attack optimization from Zhao, Ding, and Yang makes the memory-access costs practically disappear: https://t.co/Qs5zvH3u68
— Daniel J. Bernstein (@hashbreaker) 2024年5月20日
リンク先はこちら。
アンチKyber派のDJB氏（この辺の話はTLS季報 vol.2の第2章に書いたのでよろしくお願いします 🥺）が、新しい格子攻撃の最適化についての論文を紹介している。メモリアクセスコストを根拠に、NISTはKyber-512の安全性を主張しているが、この論文の内容によりメモリアクセスのコストはほぼなくなる、とのこと。
Chromeとかで使われてるのはKyber-768なんだけど、その辺はどうなんですかねえ...。
▼Zoomが耐量子E2E暗号化
こちらのツイートから。
Zoomがポスト量子エンドツーエンド暗号化を追加した。Zoom WorkplaceでKyber 768による鍵交換に対応。Zoom Meetingsにおいては全世界で対応済み。Zoom PhoneとZoom Roomsは近日対応予定。ポスト量子暗号化はAppleのiMessageでも最近採用された。 https://t.co/S7PDOqBrUT
— kokumoto (DM) (@__kokmt) 2024年5月21日
リンク先はこちら。
やはりここでもKyber-768。NTRU Primeを採用したSimpleX Chatがやはり特別な様子。
▼Chromeと耐量子暗号戦略
こちらのツイートから。
Blogged about Chrome's strategy for authentication in HTTPS in a post-quantum world, given that post-quantum cryptography is considerably larger on the wire than traditional asymmetric cryptography https://t.co/kE30Van9OF
— David Adrian (@davidcadrian) 2024年5月23日
リンク先はこちら。
KyberでTLS ClientHelloのサイズが30倍になることで、パケット分割され、ハンドシェイクのレイテンシが平均4%増加するものの、HTTP/2やHTTP/3のコネクション再利用のおかげであまり目立っていない様子。
TLSのアジリティを高めるためにも、Trust ExpressionsやMerkle Tree証明書などの新しい提案で、Kyber以上にサイズ増加が懸念されているサーバー証明書の問題に対応する必要があるとのこと。
そのTrust Expressionsは、先日新しいドラフトが公開された。
There is a new draft for Trust Expressions. It is trying to address the real-world complexity of TLS deployment by making the ubiquity problem of root certificates manageable it does this by enabling relying parties to succinctly convey which certification authorities they trust.…
— Ryan Hurst (@rmhrisk) 2024年5月24日
差分を見ると結構ゴリゴリ書き変わっている...。
関連して、Chromeの開発マネージャであるEmily Stark氏のツイートも。
My team has been BUSY! Highlights from this lovely Friday morning:
— Emily Stark (@estark37) 2024年5月24日
- Postquantum TLS strategy: https://t.co/2vRbLYEMTJ
- Distrusting CAs w/out breaking existing certs: https://t.co/EpNnnQB5XN
- Updated draft of Trust Expressions for TLS cert negotiation: https://t.co/WrwD7Gv2ae
Distrusting〜については↓で取り上げている。
▼GLOBALTRUST認証局の続報
こちらのツイートから。
"On numerous instances over the last three years, e-commerce monitoring GmbH fell short of the above expectations. In light of this, we have reached the conclusion that the GLOBALTRUST 2020 certificates suffer from a loss of integrity and action is required from the perspective…
— Ryan Hurst (@rmhrisk) 2024年5月24日
リンク先はこちら。
GLOBALTRUST（というかe-commerce monitoring GmbH）の件はTLS季報 vol.2の第3章に書いた（元ネタはこっち）。
そうした事件が過去3年のうちで何度かあったらしく、ChromeはWebセキュリティを確保するため、同社によって2024年6月30日以降に初めて署名されたサーバー証明書は、デフォルトで信頼しないこととすると発表した。
▼OpenSSLのRFC 9150サポート
こちらのツイートから。
[openssl] Add support for integrity-only cipher suites for TLS v1.3https://t.co/YWuDUXZAnw
— ゆき (@flano_yuki) 2024年5月24日
👀
リンク先はこちら。
TLSが暗号技術で保証しているのは、機密性（Confidentiality）、真正性（Authenticity）、そして完全性（Integrity）。
TLS1.2までの時代には暗号スイートが山のようにあり、その中にはTLS_NULL_WITH_NULL_NULLとか、TLS_RSA_WITH_NULL_SHA256とか、TLS_ECDH_anon_WITH_NULL_SHAのような、何に使うのかよくわからない暗号スイートがあった。NULLとかanonと書かれているのが、機密性、真正性、完全性のいずれかを欠いている。
TLS1.3でこういうのが入ってくるとは思わなかった...。
OpenSSL 3.4は、RFC 9150で2022年に定義されたTLS_SHA256_SHA256と、TLS_SHA384_SHA384を取り込んだ（デフォルトでは無効化されている）、とのこと。サーバー認証と、相互認証も一応サポートはされているらしい。産業機械の分野で、ロボットアームなど信頼性（完全性）が重要な通信だが、機密性はないような場面での利用が想定されている。低遅延が求められることもあって、暗号化（機密性）がスキップされているようだ。
IoTの世界は何もわからんな...。
[おわりに]
よろしくお願いします！！（ダイマ
