kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2023年10月9日～2023年10月15日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第127回の原稿）です。
全文を公開している投銭スタイルです。

[ChromeでWebサイトが表示できない場合]

こちらのツイートから。

リンク先はこちら。

https://faq.sakura.ad.jp/s/article/000001530

help.sakura.ad.jp

HTTPSファーストモードの影響、と思われる。

forest.watch.impress.co.jp

先日のLet's Encryptのツイートによると、世の中的にはまだ20%程度HTTPSでない通信が行われているらしいので、それなりに影響があるようだ。

[ACMEはいいぞ]

こちらのツイートから。

リンク先はこちら。

blog.chromium.org

Chromiumのブログが更新された。ACME（Automatic Certificate Management Environment）はいいぞ、という内容。
CA/B ForumのFace-to-Face Meetingが先日開かれたらしい（議事録はまだ公開されてなさそうだった）。Chrome Root Programポリシーの新バージョンが近々公開される予定で、主な変更としては、プログラムに加入するルート認証局のACMEサポートが必須になるとのこと。

「Moving Forward, Together（MFT）」イニシアチブ（これはポリシーではないらしい）に基づき、有効期限を90日にする話が、新しいポリシーの中でどう表現されるのか気になるところ。

[その他のニュース]

▼Oblivious PRF

こちらのツイートから。

リンク先はこちら。

Post-quantum oblivious PRFs from shallow PRFs and TFHE

martinralbrecht.wordpress.com

少し前から、Cloudflare（とMozilla）がOblivious HTTP（OHTTP）と言う仕様を提案している。クライアントのIPアドレスを隠すやつらしい。

asnokaze.hatenablog.com

それと似たようなプライバシー関連のPRFで、乱数生成のためのキーはサーバだけが知っており、入力値と出力される乱数はユーザーだけが知っている、と言うのを実現できるらしい。TLSで直接使うことはなさそうかな...?
Cloudflareが既にプライバシーパスなど、いくつかのアプリケーションとして提供しているとのこと。

developers.cloudflare.com

▼Let's Encryptにご用心？

こちらのツイートから。

リンク先はこちら。

www.itmedia.co.jp

先週の日経の記事が、まだときどき言及されている様子。

kdnakt.hatenablog.com

▼PQCとNSAの暗躍

こちらの記事から。

www.newscientist.com

ChaCha20やPoly1305、Ed25519の開発で知られるDaniel J Bernstein氏がPQCの標準化を進めているNISTを非難している。NSAがどのように関与しているかをNISTは明らかにしておらず、透明性が担保されていないとのこと。

▼Classic McEliece

こちらのツイートから。

リンク先はこちら。

www.ietf.org

Wikipediaによると、以下の特徴があるらしい。

最初の確率的な暗号方式であり，一つの平文から異なる暗号文が生成される．この暗号方式は暗号コミュニティにおいてあまり注目を浴びてこなかったが，ショアのアルゴリズムを用いた攻撃で破ることができないため，耐量子暗号の候補の一つ

標準的なパラメータでは公開鍵が512KBということで、Kyberが1KB程度なのと比べるとかなり大きめ。TLSで使われることはなさそう？

PQCzooでも取り上げられていた。

pqczoo.com

▼もうすぐIETF 118

こちらのツイートから。

リンク先はこちら。

datatracker.ietf.org

IETF118は11月4日-10日にプラハで開かれる予定。TLSのミーティングは日本時間11月6日(月)17:30-19:30とのこと。仕事の都合がつけば、見れなくもない時間帯。アジェンダを見て考えるか...と思ったが、アジェンダはまだ出ていない様子。

[暗認本：26 SHA-2とSHA-3]

引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 5 認証から、セクション26をざっとまとめた。

  • SHA-2
    • 2001年NISTが標準化。ハッシュ値のサイズは224, 256, 384, 512ビット
    • SHA-224/SHA-256、SHA-384/SHA-512は内部動作がほぼ同じ
    • SHA-256
      • 512ビットずつに分割＋余り＋パディング＋データ長64ビット整数
      • 次のようなマークル・ダンガード構成を採用（MD5やSHA-1でも利用）
      • 256ビットの初期値を用意し、分割したブロックと圧縮関数fを順に適用する S1=f(S0, B0), S2=f(S1, B1) ... h=f(Sn+1, padding)
      • 圧縮関数fの詳細については省略...
    • 64ビットCPUの場合SHA-512の方が高速なこともある（ビット演算の回数が少なくなるため）
  • SHA-3
    • 2012年にコンペで選ばれたKeccakと言うハッシュ関数が2015年標準化
    • ハッシュ値のサイズはSHA-2と同じ224,256,384,512
    • マークル・ダンガード構成でなくスポンジ構造を採用：吸収フェーズabsorbingと搾取フェーズsqueezing
      • ハッシュ値のサイズに変わらず1600ビットの内部状態と同じ置換関数fを使う
      • r＝1600-ハッシュ値のサイズ*2とする（SHA-3-256ならr=1088）
      • データをrビットずつ分割してパディング付与
      • 内部状態の先頭rビットと分割したデータで排他的論理和をとり内部状態を更新したものに、置換関数fを適用するのを繰り返して「吸収」する
      • 最終的に内部状態から先頭256ビットを「搾取」する
  • 安全性
    • ハッシュ関数の安全性はハッシュ値のサイズで決まる
    • SHA-256とSHA-3-256の安全性は理想的には同じ
    • 2020年時点でSHA-2のフルラウンドに対する現実的攻撃はなし
    • ビットコインでもSHA-256が使われている

[まとめ]

先週のニュースのURLで開催回数を間違えていたのはナイショ。

技術書典向けに書いてるやつは12000字くらいになった。そろそろ仕上げねば...。

ランキング参加中
プログラミング

※以降に文章はありません。投銭スタイルです。

*1:TLSらじおは社内勉強会です。このブログを読み上げつつ弊社サービスの実情を語ったりします。

この続きはcodocで購入