AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...

ChaCha20-Poly1305 將被移植到 OpenSSH 上...

Slashdot 上看到 ChaCha20-Poly1305 將被移植到 OpenSSH 上:「OpenSSH Has a New Cipher — Chacha20-poly1305 — from D.J. Bernstein」。

上個月 Google Chrome 決定在 32 版 (現在 31 版了) 要支援 ChaCha20-Poly1305 (參考「Google 對四個 Cipher 的分析... (以及 ChaCha20-Poly1305)」),這個月 OpenSSH 就打算要跟進了...

提案人 Damien Miller 在 blog 上提到為什麼他想將 ChaCha20-Poly1305 移植到 OpenSSH 上的原因 (「ChaCha20 and Poly1305 in OpenSSH」),主要是因為 AES-GCM 與 Encrypt-then-MAC 都必須傳輸 plaintext 的長度,這點讓人很不舒服。另外一個是 AES-GCM 的效能一直都是個議題。

ChaCha20-Poly1305 以 stream cipher 企圖同時解決這兩個問題,接下來就是看時間考驗了...

Google 對四個 Cipher 的分析... (以及 ChaCha20-Poly1305)

Google Online Security Blog 上對四種 cipher 的分析:「A roster of TLS cipher suites weaknesses」。

分別是 RC4、AES-CBC、AES-GCM、ChaCha20-Poly1305 四個 cipher。其中 RC4 與 AES-CBC 的問題都很多,而 AES-GCM 與 ChaCha20-Poly1305 是目前還沒有有效攻擊的 cipher。

前面三個都算熟悉,第四個是到是頗意外會出現... 不過 ChaCha20-Poly1305 不只一家打算跳下去實做了:

ChaCha20 與 Poly1305 都是 D. J. Bernstein (djb) 的作品,不知道 OpenSSL 會不會納進去...

在「ChaCha20 and Poly1305 for TLS」這邊有些為什麼有了 AES-GCM 後還要用 ChaCha20-Poly1305 的原因,主要是速度考量。兩者的速度差非常多...

因為 NIST 而換掉 AES?

Slashdot 上看到有人因為最近 NIST 被抖出來的事蹟 (SHA-3 的問題),而決定換掉 AES:「Silent Circle Moving Away From NIST Cipher Suites After NSA Revelations」。原報導在「Non-NIST Cipher Suite」。

換掉 AES 不確定這是不是好主意...

Rijndael 從 1998 年公開後,2001 年被選為 AES,之後被廣泛應用在所有資安協定上,也因為被廣泛應用,全世界打了這十多年下來,都還是屬於可用的狀態。換成其他 cipher 會比較安全嗎?

加快 SSL 加解密速度...

看到 Ash Wu 貼的「5 easy tips to accelerate SSL」:

先列出原作者在文章裡給的結論:

ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:+HIGH:+MEDIUM

不過,現在考慮 SSL 效能以行動平台為主 (因為桌機用軟體計算也超快),而行動平台中 iOS 可以對 AES 與 SHA1 硬體加速 (iOS 4.3+),Android 一般的情況下看起來沒得用,所以就自己取捨啦...