length

Amazon SES 總算支援 2048 bits RSA key 了

Amazon SES 總算是支援 2048 bits RSA key 了：「Amazon SES now supports 2048-bit DKIM keys」。

然後講一些幹話... 隔壁微軟早在 2019 年就支援 2048 bits RSA key 了：

Until now, Amazon SES supported a DKIM key length of 1024-bit, which is the current industry standard.

另外用 ECC 演算法的一直都沒進 standard，像是已經先 book 了 RFC 8463 位置的 Ed25519，在 draft 狀態放好久了：「A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)」，還有用 ECDSA 的「Defining Elliptic Curve Cryptography Algorithms for use with DKIM」也是放著，不知道是卡到什麼東西，可能是專利？

NIST 對密碼學演算法建議的長度 (2020 版)

在「Comparing SSH Encryption Algorithms - RSA, DSA, ECDSA, or EdDSA?」這邊一路翻到「Keylength - NIST Report on Cryptographic Key Length and Cryptoperiod (2020)」這篇，裡面引用的是 NIST 的「NIST Special Publication 800-57 Part 1 Revision 5」。

在 NIST 的文件裡面，不同的演算法散落在不同地方，Keylength 整理起來後比較方便看。

想要特別拉出來講是因為看到 RSA 2048 bits 被放到 112 這個等級 (Security Strength)，我一直以為是 128，不過查了一下發現好像以前是就 112 了...

SWEET32：攻 Blowfish 與 3DES

最新的攻擊算是實戰類的攻擊，理論基礎以前都已經知道了，只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊，而這些演算法剛好還是被用在 TLS 與 OpenVPN 上，所以嚴重性比較高：「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。

攻擊的條件是 block cipher 的 block size，而非 key length，所以就算是 256 bits 的 Blowfish 也一樣也受到影響。

這次順利打下 Blowfish 與 3DES。這兩個 cipher 的 block size 都是 64 bits，所以對於 birthday attack 來說只要 2³² 就可以搞定：

This problem is well-known by cryptographers, who always require keys to be changed well before 2^n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2^n/2 blocks, and many implementations don't enforce any limit on the use of a key.

在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher)：

In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.

以及 HTTPS 打 3DES 的部份 (為了相容性問題)：

Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

都是有可能的等級。也該來拔掉對 IE8 的支援了... orz

V8 的 Math.random() 亂度不足的問題

在「TIFU by using Math.random()」這篇看到作者踩到地雷，於是在討論 V8 Engine 的 Math.random() 的亂度不足。

其實這個問提早在 2012 年就有人在 StackOverflow 上詢問：「Why is Google Chrome's Math.random number generator not *that* random?」，而且也回答得很清楚。

而 Mozilla 這邊在 2006 年也被提出了類似的問題：「Bug 322529 - Upgrade Math.random() to a better algorithm, such as Mersenne Twister」。

文章中間花了許多篇幅講 PRNG 的介紹，以及 cycle length 的說明，重點其實在結論的部份。

主要是因為 V8 Engine 的 Math.random() 實作的是 MWC1616 演算法 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines)，而這個演算法用起來也綁手綁腳：

If you’re only using the most significant 16 bits it has a very short effective cycle length (less than 2³⁰).

有兩個方向可以改善 (不衝突的方向)，一個是使用 CSPRNG (保證有極長的 cycle length)，另外一個請求 V8 Engine 把 Math.random() 的演算法換掉，像是 MT19937 這類 cycle length 超級長的演算法。

不知道後續有沒有機會改善...

增加密碼的長度比其他各種限制有效

在「Why is length > complexity? Because math...」這篇以組合數的角度提出了密碼的長度比起其他的各種限制來的有效。

(出自「xkcd: Password Strength」)

這是在考慮到 threat model 與使用者習慣的平衡性，要求使用者要有大小寫數字特殊字元，不如簡單要求長度就好，對於密碼資料庫外洩時對抗暴力法比起要求複雜度來得有抵抗性，而且使用者反而不用記一堆特殊字元。

不過如果能用 KeePass 或是 KeePassX 這類密碼管理工具的話會更好，都是直接開到可以接受的最大上限，而且每個站都不一樣的密碼會更有防禦力，而針對密碼資料庫的 password 就可以硬背超長字串... (因為只要記一個)

同時用 mod_deflate 與 mod_fastcgi 所產生的問題...

今天花了不少時間找到的問題...

問題是使用 mod_fastcgi 以及 mod_deflate 時，Content-Encoding 會是 gzip，但 Content-Length 會是未壓縮的長度。

也就是說，伺服器端在 header 提供的 Content-Length 可能寫 8KB，但實際上只丟出 2KB (壓縮後的大小)，於是瀏覽器讀完這 2KB 後會停下來一直等，等到 Keep-Alive timeout 斷線 (在我機器上預設是 5 秒)。

在 timeout 斷線後 browser 會就抓到的資料直接解開執行 (因為這 2KB 都有抓到，於是都正確執行)。如果用瀏覽器這邊的 debugger 觀察，就會發現從 first byte 後 5.00 秒才 document ready。

解法有人在 2008 年給過：「Content-Length header should be set using ap_set_content_length」，不過因為 mod_fastcgi 一直沒出新的正式版，所以大家都還是拿到舊的版本。

所以，與之前修正 multi-threading 的問題一樣，往 ports 本身丟 patch：「Update www/mod_fastcgi to fix mod_deflate issue.」，修正後再測試就正常了。