kdnakt blog

hello there.

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

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

[Large Record Sizes for TLS & DTLS]

こちらのツイートから。

リンク先はこちら。

www.ietf.org

あたらしいインターネットドラフトが出た。
RFC 8449 TLS 1.3では、TLSレコードサイズを2^14(16384バイト)に制限しており、「record_size_limit」というTLS拡張を利用すると、より小さい上限値を設定することができる(知らなかった...)。

www.rfc-editor.org

TLSレコードサイズを増やすことは認められていなかったが、元々TLSレコードのlengthフィールドはuint16型で65535バイトまで設定可能であり、DTLS over SCTP(RFC 6083)など特定のユースケースでは2^14の制限が厳しいという背景がある。そのため今回、TLSフラグ拡張で新しく「large_record_size」TLSフラグを導入し、「record_size_limit」TLS拡張と合わせて使用することで、TLSレコードサイズを2^14以上に設定可能とするとのこと。ただし、最大長は2^16 - 1で、実際にメッセージとして利用できるのは2^16 - 257 = 65279バイトとなるとのこと。

datatracker.ietf.org

TLSレコード長が増える=暗号化対象のメッセージの量が増えるということで、同じキーで暗号化できるレコード数の制限は4分の1に減ることになるらしい。なるほど。

DTLSよくわからんけど、TLSでも使うケースあるんだろうか...?

[Cryptography & Security Newsletter #110]

こちらのツイートから。

リンク先はこちら。

www.feistyduck.com

トップニュースはiMessageのPQ3プロトコル

また、EUのeIDAS規制についてはWebブラウザベンダに影響しないとの明言があった様子。

Rustlsのアップデートがあり、AWS Libcryptoをバックエンドとし、アメリカの政府標準であるFIPSをサポートするようになったとのこと。

Rustls Now Using AWS Libcrypto for Rust, Gains FIPS Support - Prossimo

その他のニュースでは以下の通り。

他は、E2E暗号化に関する話題が多めっぽい。

[その他のニュース]

WindowsのCTLM policy

こちらのツイートから。

リンク先はこちら。

learn.microsoft.com

Microsoftが信頼するCTログサーバのリストが月次でアップデートされるようになったらしい。

また、今後のリリースで、証明書の透明性検証をオプトインできるようになるとのこと。逆にいうと今できてないってこと...?EdgeはChromeベースで、ChromeがCT検証してるから当然やってるものだと思ってたけど、それ以外の話なんだろうか...。
あ、CTLM(Certificate Transparency Log Monitor)のリストにあるCTログサーバからのCT検証をオプトインできる、って話かも?

また、e-Tugraをはじめとするいくつかのルート証明書が無効化されたり、TurkTrustをはじめとするルート証明書が削除されるとのこと。

▼ひとくちPKI 64

こちらのツイートから。

リンク先はこちら。

podcasters.spotify.com

Google Trust Servicesのインシデントの話、Chrome Root Program Policy, Version 1.5の話、などなど。

chrome.security

こちらのツイートから。

リンク先はこちら。

chrome.security

Chromium BlogGoogle Security Blogまとめサイト的な感じ。

TLS Trust Expressions解説

こちらのツイートから。

リンク先はこちら。

github.com

新しいドラフトが出てるっぽい。

davidben.github.io

概要は以前取り上げた通り。

kdnakt.hatenablog.com

代替案として、certificate_authorities拡張や、TLSフィンガープリントが検討されていた様子。

[暗認本:45 準同型暗号]

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

  • 準同型
    • ある構造を持った2つの世界の間の対応がその構造を保つこと
      • 例)ゲームのコントローラとキャラクター
    • 準同型暗号:整数からなる平文の世界と暗号文の世界が対応
      • 整数なので、暗号でも(普通はできない)足し算や引き算ができる
      • 例)5 x 2 = 10,  Enc(5) x 2 = Enc(10)
    • 準同型暗号ではEnc()の引数に平文mと乱数rをとり、平文と暗号文の対応が1:1でない
  • 加法準同型暗号
    • 準同型暗号のうち、足し算・引き算だけができるもの
    • 例)Paillier暗号、lifted ElGamal暗号など
    • 整数倍も可能:Enc(m) x n = Enc(m x n)
  • 完全準同型暗号
    • 暗号文同士の掛け算もできる加法準同型暗号
      • 例)Enc(10) x Enc(3) = Enc(30)
    • 1ビットの世界...加算=排他的論理和、乗算=論理積
    • コンピュータの任意の計算は排他的論理和論理積の組み合わせで実現可能
      • 平文の世界でmを変換する回路fに対応する、暗号文の世界の暗号回路f'を作れる
    • 完全準同型暗号の実現は長らく未解決だったが2009年Gentryが提案し、以後改良が続いている
    • 現在は格子暗号が高速な完全準同型暗号。耐量子暗号としても注目。
  • 準同型暗号の種類と用途
    • 完全準同型暗号は演算処理が重い、公開鍵や暗号文が巨大
    • 暗号文同士の乗算回数に制約を入れたレベル準同型暗号も提案されている
      • 2レベル〜(乗算1回まで)、Nレベル〜(乗算N-1回まで)
    • 具体的な用途の一例)購買履歴のクロス集計:個々のデータは暗号化したまま、乗算回数は高々1回なので2レベルでもOK
    • 準同型暗号は秘匿性はあるが、完全性はない...別途MACや署名で保護が必要

[まとめ]

暗認本が最終章に入った。終わったらニュースオンリーに戻ろうかな...。