kdnakt blog

hello there.

今週気になったTLS関連のニュース

2024年3月11日~2024年3月17日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第148回分。

[2024年の耐量子暗号]

こちらのツイートから。

リンク先はこちら。

blog.cloudflare.com

鍵合意アルゴリズムについては、Chromeなどのブラウザのサポートもあり、方向性がほぼ決まった気がする。

証明書はどうなってるんだろう、RFCもX.509の標準もよくわからん...という気分でいたが、こちらの記事によれば、CAがHSMを利用して耐量子暗号を使用した証明書を発行できるようになり、監査が完了し、CA/B Forumが新しいアルゴリズムの使用を承認する必要があるため、2026年以降になるだろうとのこと。
耐量子証明書の実運用は、まだまだ先になりそう。古いクライアント向けに複数の証明書をデプロイするパターンとかは大変そうだなあ...。

NISTのドラフトが出ているML-DSA(Dilithium)やSLH-DSA(SPHINCS+)といったPQC署名以外にも、PQC署名追加コンペで出てきているMAYOやUOV、HAWKも取り上げられていた。TLS関連で単に署名といった時に、X.509証明書だけを考えていたけど、CTで利用されるSCTの署名や、OCSPステープルの署名もあるとの指摘が。確かに...。
そして、SCTの署名の場合は証明書と異なり公開鍵が転送されないので、MAYOやUOVのように公開鍵のサイズがデカくても問題ないらしい。
関連して、中間証明書の省略、TLS Trsut Expressions、KEMTLS、Merkle Tree Certificate、といったインターネットドラフトが解説されていた。個々のドラフトはなんとなく読んでいるけれど、全体をこうして繋げて読んだことがなかったのでとても勉強になる。

[Sunlight:スケーラブルなCT実装]

こちらのツイートから。

リンク先はこちら。

letsencrypt.org

Let's Encryptの新しいCTログ実装が出たとのこと。Merkle Treeをタイル化する云々の件はなんか記憶にあるな、と思ったら1月のニュースでちょうど取り上げた仕様が実装された、ということのよう。CTログといえば、ログツリー本体へのマージ遅延の問題があったが、これも解消する仕組みになっているらしい。

kdnakt.hatenablog.com

[その他のニュース]

▼ML-KEMとCRYSTALS-Kyberの差異

こちらのツイートから。

耐量子暗号の鍵交換アルゴリズムとしてNIST(米国国立標準技術研究所)のPQCコンペティションを勝ち残ったCRYSTALS-Kyberと、それをもとにNISTが標準化しようとしているML-KEMとでは、何やら差分があるらしい。

typo説もあるようだが、バックドアの類を疑うのはやりすぎ?

▼LibreSSL 3.9.0

こちらのツイートから。

リンク先はこちら。

www.mail-archive.com

BoringSSLと互換性のあるAPIを用意したりしているらしい。

GoogleのPQC脅威モデル

こちらのツイートから。

リンク先はこちら。

bughunters.google.com

store now, decrypt laterと、固定の公開鍵の使用期間などを軸に耐量子暗号についての考察。だけど"Fancy" cryptographyってなんの話だろう...。

ファームウェア署名、ソフトウェア署名にもSPHINCS+(SLH-DSA)が推奨されている様子。JWTはCookieの関係で上限があるが、Dilithium3署名はこの要件を満たさないとのこと。

▼EntrustのEV証明書インシデント

こちらのツイートから。

リンク先はこちら。

bugzilla.mozilla.org

EntrustというCAが発行したEV証明書10数件に、本来必須となっている証明書ポリシーのURI(cPSuri)が不足していた、というインシデントが発生したとのこと。どうやらCA/B Forumの提供するいくつかのドキュメント間の不整合によって発生したらしい。

しかしながら、Entrustは問題を修正せず、問題のある証明書を発行し続けていることから、議論の的になっている様子。

▼CAオーナー別市場シェア(2024/03)

こちらのツイートから。

CTの事前証明書ベースでの発行数の比較。Let's Encrypt、GoDaddy、Google Trust Servicesがシェアを伸ばしている様子。

▼FastlyのTLS対応

こちらの記事から。

www.fastly.com

picotlsに機能追加し、neverbleedというOpenSSLエンジンを利用して非同期ハンドシェイクをサポートするようにした結果、パフォーマンスが向上したとのこと。

▼ECHのIPフラグメンテーション

こちらのツイートから。

リンク先はこちら。

mailarchive.ietf.org

NginxでEncrypted Client Hello利用時に接続が中断されてしまうケースがあるとのこと。フラグメンテーションが原因との説もあるが、単にNingxのバグではという話もある。はて...。

[暗認本:47 ゼロ知識証明]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 9 高機能な暗号技術のセクション47をまとめた。

  • 動機
    • 秘密計算で秘匿化されたデータの処理時に入力値が適切かどうか確認するための仕組みが必要
    • 例)秘密投票:投票者1~N(1or0で投票)->集計サーバ->結果確認者。集計サーバが2以上の値でないことを知る必要がある
  • ゼロ知識証明
    • 1985年に定式化された手法:秘密鍵を教えずに、平文が適切であることを示す
    • 似た例)署名は秘密鍵(署名鍵)を公開していない
  • ゼロ知識証明の性質
    • 完全性:命題が正しいなら検証者は必ず納得する
    • 健全性:検証者が納得したならほぼ100%命題は正しい(証明者が嘘を言った場合、検証者は納得しない)
    • ゼロ知識性:検証者は命題が正しい以外の情報を得られない
  • ゼロ知識証明とブロックチェーン
    • ブロックチェーンで、A円持ってる人がB円送金しC円残った(A=B+C)ということを秘匿したいケース
    • 2012年にzk-SNARKという効率的ゼロ知識証明が提案された
      • zero-knowledge Succinct Non-interactive ARgument of Knowledge(信頼できる第三者機関が必要)
    • 非対話証明:1度データを送るだけで良いのでプロトコルが簡単
    • アーギュメント:証明と異なり証明者の計算能力を限定して見積もることで効率化する
    • 三者機関不要なBulletproofやzk-STARKなどのプロトコルもある(証明のサイズや耐量子性などが異なる)

[まとめ]

今週も耐量子暗号関連の話題が盛りだくさん。そもそも基本の暗号自体がちゃんと理解できてないのにこれでいいんだろうか。