2024年8月26日～2024年9月1日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第171回分。
[Cryptography & Security Newsletter #116]
こちらのツイートから。
Cryptography & Security Newsletter is out! In this issue:
— Feisty Duck (@feistyduck) 2024年8月29日
- Post-Quantum Cryptography Arrives
- Short Newshttps://t.co/seT7lyL6rz pic.twitter.com/6zi8MNAlKT
リンク先はこちら。
ヘッドラインはNISTの耐量子暗号標準の公開の件。
気になったショートニュースは以下の通り。
- 自宅用ソーラーパネルシステムが512bitのRSA暗号を利用
- Sectigoがいくつかのリンターを統合したPKI Meta-Linterを公開
- DJ Bernstein氏「C言語でタイミング攻撃防止は難しい」
- Kerberosプロトコルとスマートカードの脆弱性
- タイミング攻撃発見用ツールRTLF
- 2Gモバイルネットワークのパッシブ攻撃（特に組み込み系）
- 独自の暗号化コードを書く際のよくある間違い
[その他のニュース]
▼OpenSSLとRustls
こちらのツイートから。
opensslって奴をやめてrustlsに差し替えるだけでメチャクチャにハンドシェイクの性能が上がるのを観測したんだが、rustlsとopensslでそこまで差がある？（重いのなんてほぼ暗号系の処理くらいだろうし実装を切り替えるくらいでそこまで差分が出るのか気になる）
— しくがわ (@_iy4) 2024年8月24日
opensslはv3から証明書読込が遅い問題があるのを観測してます。（v1と比べて数百ミリ秒単位で遅くなった） これかも？https://t.co/pO495Y0rnH
— うめ (@bungoume) 2024年8月25日
数百ミリは結構深刻ですね...最近観測したのだと、v3系でwriter starvation的な問題が発生してデッドロック状態になるみたいのも引いてしまいました https://t.co/b2IMDcLb3H
— しくがわ (@_iy4) 2024年8月25日
というよりは、ハンドシェイクの鍵共有の部分が速いんじゃないかなと思っています。（あまり詳しいことは話せないですが）ハンドシェイクの開始をヘビーに行うようなワークロードなので、そこでrustlsのハンドシェイク性能の優位性が発揮されているような形に見えますね https://t.co/6PIGIOYRdS
— しくがわ (@_iy4) 2024年8月25日
Rustlsで、証明書読み込みだったり、暗号処理（鍵共有）だったりがOpenSSLより速くなってるっぽい。気になる。
▼TLSNotary
こちらのツイートから。
#ETHTokyo でTLSNortaryとzkMLを組み合わせ、Infrastructure and tooling 部門で1st Prize を獲得しました🥇
— wasabi (@wasabijiro) 2024年8月25日
スポンサー賞もいただきました！
🏆NERO Prize 1st place
💰Mercoin Prize
💰ENS Prize
💰NEO-X Prize
💰Scroll Pool Prize
w/ @JunK_0908 @suhara_pontahttps://t.co/nwGHvgx3Di
リンク先はこちら。
この発表自体は暗号通貨の話っぽい。詳しくないので省略...。
TLSNotaryという新しいプロトコルが使われている。データを第三者に提示する時にその信頼性をどう担保するか、みたいな話っぽい。スクショとかだと、いくらでも偽造できちゃうからね...。
▼Let's Go Quantum!
こちらのツイートから。
Go 1.23 enables post-quantum encryption by default. Great to see a talk at Gophercon to highlight it. https://t.co/hJs1chH57s
— Bas Westerbaan (@bwesterb) 2024年8月26日
リンク先はこちら。
GopherConUKでの発表。Go 1.23でHTTPSサーバを起動する際に、楕円曲線X25519と耐量子暗号Kyberの組み合わせによるハイブリッド鍵交換がデフォルトで有効化されたらしい。
▼耐量子Web PKIの構築
こちらのツイートから。
Chrome team laying out thoughtful constraints for a (completely overhauled) post-quantum WebPKI. Please have a look. Hopefully we'll never get the chance to change the WebPKI as dramatically again. https://t.co/ZSza4OiHYe
— Bas Westerbaan (@bwesterb) 2024年8月27日
リンク先はこちら。
Chromeチームが設計原則や制約をまとめてくれている。証明書の誤発行の問題、ハンドシェイクのデータサイズを小さく保つ、などなど耐量子暗号特有の問題から、古いクライアントのサポートやプライバシーの問題など新しい暗号への移行時の一般的な問題まで。
▼HTTPS localhost with Next.js
こちらのツイートから。
HTTPS localhost with Next.js pic.twitter.com/zF9hUECWZc
— Alex Sidorenko (@asidorenko_) 2024年8月29日
Next.jsでローカルでHTTPS接続ができるオプションができたらしい。といっても1年前のバージョンだけど...。サードパーティのAPIがHTTPSを必要とするケースがあるとか。
こんな感じで、mkcertを使っているっぽい。
% npm run dev
> my-app@0.1.0 devs
> next dev --experimental-https⚠ Self-signed certificates are currently an experimental feature, use with caution.
Downloading mkcert package...
Download response was successful, writing to disk
Attempting to generate self signed certificate. This may prompt for your password
Sudo password:
CA Root certificate created in （省略）
Certificates created in （省略）
Adding certificates to .gitignore
▲ Next.js 14.2.7
- Local: https://localhost:3000✓ Starting...
✓ Ready in 1370ms
OSSでの証明書というと、以前preact-cliが同じような目的でルート証明書と秘密鍵を配布してしまっていたことにより、MITMを誘発する問題があった。今回はmkcertが秘密鍵を生成するので、preact-cliと同じ問題はなさそう*1。
[おわりに]
暗号は厄介な技術なのかなあ...。
Winnyの事件を彷彿とさせるが、開発者の意図や悪質性を立証できるんだろうか？匿名性や暗号化自体が「厄介な技術」として認識されつつあるのだろうか？ https://t.co/3h3ImOIcWk
— Ichihara Hajime / 市原創 ー『SSL/TLS実践入門』 (@haj18) 2024年8月25日
*1:preact-cliの脆弱性を知ったのは、TLSらじお第26回のとき。badssl.comは勉強になるなあ。
