Masanori Ogino @omasanori@mstdn.maud.io

結局、安心して使えるコンピューターが欲しいんだよなという自分の気持ちに気づいた

btrfs-progs？

本物になりたい

暗号、いつかちゃんと学びたいですね

ああ、例のアナウンスってArm-to-x86バイナリトランスレーションがないとAndroid-x86で動かなくなるって意味なんですね

Ed25519 EdDSA + X25519 ECDH + ChaCha20-Poly1305という組み合わせをいつかやってみたくはある（現時点での実用性は多分ない）

Android-x86プロジェクトでやっているものから離れれば離れるほどマージ業が大変になりそう

パラノイドに振り切ると「うちのMastodonはAES-256のみ、ECDHはsecp521r1だ！」とかなる（反NSAなら別）んですが、RSA証明書を使っていると対応する強度の鍵長が15000ビット越えとかになってアになる

なので、P-256（鍵長は名前の通り256ビット）がAES-128と同等と考えられているという話になります（ちなみにRSAやDHだと3072ビットの鍵がこれらと同等とされていて、これがRSA証明書の鍵長がAESの鍵長よりもやたら長くなっている理由）

暗号アルゴリズムの強度は「Nビットのセキュリティレベル」という言葉でよく言及されるのですが、これは大雑把にいうと「2^N回の試行で破れる」という意味を持ちます。AESのような共通鍵暗号だと（効率の良い手法が見つかっていない限り）「Nビットのセキュリティレベル」と「鍵長はNビット」は同じ意味ですが、他の種類の暗号だとその手法によって鍵の大きさが変わります

設計上の強度でいうと、P-521 > Curve448 > P-384 > Curve25519 = P-256で、P-256はAES-128と、P-521はAES-256と対応する強度と考えられている

この順だと、
・古い環境：P-384かP-256
・そこそこ新しい環境：P-256
・新しい環境：X25519
になりがち（X25519とP-256は設計上の強度が同じ、P-384は他の2つよりも強いが、オーバーヘッドも上乗せされる）

最近のブラウザーで採用が相次いでいるX25519（軽くていくつかの良い性質を備えているCurve25519楕円曲線を使う）、ECDHをサポートしているブラウザーならまず間違いなくサポートしているNIST P-256（prime256r1のこと）、同じくNIST P-384（secp384r1のこと）の順がLibreSSLでのデフォルト設定

後はssl_ecdh_curveでECDHで使う曲線を指定できるくらいでしょうか（パラノイドにやるならsecp521r1:secp384r1:prime256v1とかになるでしょうけれど、そこまでしなくてもな……という気持ちがある）

いらないというか除外するようにして良さそう（cipher suiteのWEAKはただのHIGHに由来していて、TLS 1.2をサポートする環境なら大抵DHEかECDHEをサポートしているので）

多分ただのHIGHはいらないっぽい

評価結果を見て になった

（temporary redirectなのか……）