nginx 推出了 1.14.0 的 PPA

nginxPPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。

這個版本使用了 OpenSSL 1.1.0,對 cipher 這塊最大的差異主要是包括了 CHACHA20AESCCM 演算法。後者的 CCM 指的是 CCM mode,這是當時 OCB mode 因為專利問題而發展出來的演算法,就目前的效能測試沒有 GCM 好,而且普及率也沒有 GCM 高,放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選):

The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.

真正的重點在於 CHACHA20 的引入,讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。

不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明),目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息,但暫時還不會有效果...

OpenSSL 1.1.1 將支援 TLS 1.3

OpenSSL 的文章「Using TLS1.3 With OpenSSL」提到了:

The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3.

另外也提到了 TLS 1.3 的標準是 blocker,在 TLS 1.3 沒出來前不會出 OpenSSL 1.1.1:

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised.

OpenSSL 實做的 TLS 1.3 支援了這些 cipher:

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

GCM 的部份不算意外,比較特別的是包括了 ChaCha20Poly1305 (喊很久了),另外包括了 CCM mode 的實做...

OpenSSL 1.1.0

看到「OpenSSL 1.1.0 released」這篇得知大家期待已久的 OpenSSL 1.1.0 出了,在 1.1.0 的重要新功能中,對 ChaCha20 + Poly1305 的支援算是大家等很久的:

  • Support for ChaCha20 and Poly1305 added to libcrypto and libssl

由於 RC4 已經被證明不安全,OpenSSL 內變成沒有堪用的 stream cipher,這邊總算要補上來了...

另外兩個也頗有趣的:

  • Support for scrypt algorithm
  • Support for X25519

多了些東西...

密碼系統的 Monoculture

這篇文章講到最近密碼系統的現象:「On the Impending Crypto Monoculture」。

目前常在用的密碼系統包括了 RSA、DH、ECDH、ECDSA、SHA-2、AES 這些演算法,而最近這幾年大家在推廣使用的演算法都出自於同一個人手裡,Dan Bernstein,也就是 djb:

A major feature of these changes includes the dropping of traditional encryption algorithms and mechanisms like RSA, DH, ECDH/ECDSA, SHA-2, and AES, for a completely different set of mechanisms, including Curve25519 (designed by Dan Bernstein et al), EdDSA (Bernstein and colleagues), Poly1305 (Bernstein again) and ChaCha20 (by, you guessed it, Bernstein).

這些演算法或是定義,包括了 Curve25519、EdDSA、Poly1305、ChaCha20。而這篇文章試著說明造成這樣情況的背景以及原因,以及這樣會導致什麼問題。

當實際分析時會發現,檯面上沒幾個能用的演算法,而看起來能用的那幾個又有專利 (像是 OCB),不然就是看起來被 NSA 放了一些說明不了的參數 (像是 P-256 Curve)。

然後 djb 弄出來的演算法不只看起來乾淨許多,也直接用數學模型證明安全性。而且他的實作也很理論派,像是還蠻堅持要做到 constant time implementation 以避開各種 side channel attack。

就... 理論很強,又很實戰派的一個人啊,檯面上真的沒幾隻可以打的贏啊 XD

CloudFlare 對 Go 上面加解密系統的改善

CloudFlare 發佈了自己版本的 Go,修改了其中的 crypto subsystem:「Go crypto: bridging the performance gap」。

文章花了不少篇幅介紹 AEAD (Authenticated Encryption with Associated Data),而目前 CloudFlare 支援的是 AES-GCM 與 ChaCha20-Poly1305,也是兩大主流,分別佔了 60% 與 10% 的 HTTPS 流量:

As such today more than 60% of our client facing traffic is encrypted with AES-GCM, and about 10% is encrypted with ChaCha20-Poly1305.

CloudFlare 提供的改進使得速度快很多,並且有考慮到 side-channel attack 的問題:

Both implementations are constant-time and side-channel protected.

                         CloudFlare          Go 1.4.2        Speedup
AES-128-GCM           2,138.4 MB/sec          91.4 MB/sec     23.4X

P256 operations:
Base Multiply           26,249 ns/op        737,363 ns/op     28.1X
Multiply/ECDH comp     110,003 ns/op      1,995,365 ns/op     18.1X
Generate Key/ECDH gen   31,824 ns/op        753,174 ns/op     23.7X
ECDSA Sign              48,741 ns/op      1,015,006 ns/op     20.8X
ECDSA Verify           146,991 ns/op      3,086,282 ns/op     21.0X

RSA2048:
Sign                 3,733,747 ns/op      7,979,705 ns/op      2.1X
Sign 3-prime         1,973,009 ns/op      5,035,561 ns/op      2.6X

AES-GCM 與 EC 的改善主要是利用 CPU 指令集加速:

[T]herefore we created assembly implementations of Elliptic Curves and AES-GCM for Go on the amd64 architecture, supporting the AES and CLMUL NI to bring performance up to par with the OpenSSL implementation we use for Universal SSL.

不過 RSA 的部份雖然幅度也不小 (比起 AES 與 EC 的部份是不大,不過純就數字來看,快了一倍多也不少),不過沒提到怎麼改善,只稍微帶過:

In addition the fork includes small improvements to Go's RSA implementation.

CloudFlare 宣佈停用 RC4,並且支援 ChaCha20+Poly1305

CloudFlare 同時宣佈了停用 RC4 與支援 ChaCha20+Poly1305 的計畫:「End of the road for RC4」、「Do the ChaCha: better mobile performance with cryptography」。

2014 年年初的時候,CloudFlare 先把 RC4 從 TLS 1.1+ 的連線拿掉,而 2014 年五月時,再把 RC4 搬到 cipherlist 裡優先權最低的,成功的讓 99.9991% 的 request 改用 AES3DES (大約五個 9 ):

而九個月後的現在,CloudFlare 上 RC4 使用的比率則是降到了 0.000002%,反過來說也就是 99.999998% 的等級 (七個 9),也讓 CloudFlare 決定直接停用掉 RC4。

另外一個重大的新進展則是 ChaCha20+Poly1305,兩個都是 Daniel J. Bernstein 的作品。其中 ChaCha20 是 stream cipher,Poly1305 是 MAC。

由於 RC4 已經不夠安全,在行動平台上要夠安全必須使用 AES,但 AES 在 ARM 上面還沒有普及:在 Nexus 6 用的 ARMv7 不支援,是透過 Qualcomm Snapdragon 805 的加掛模組做的,而在低階手機支援度就更不用說了。

Google 大力推動 ChaCha20+Poly1305 的目的,是為了在行動平台上找到一個與 RC4 可以匹敵的速度,而且有著可以超越 AES-GCM 安全性的 cipher+MAC。

在 CloudFlare 採用 ChaCha20+Poly1305 前,Google 是唯一一個在 HTTPS 上大幅採用的單位,而瀏覽器的部份也只有 Google Chrome 有支援。雖然 Firefox 一直有喊著要支援,但這是個雞生蛋蛋生雞的問題,可以看到進度不怎麼快 (Bug 917571 - Support ChaCha20+Poly1305 cipher suites)。

CloudFlare 支援之後,使用 ChaCha20+Poly1305 的 pool 瞬間大了不少。可以看到一上線的使用率不算低,瞬間就有 10% 了:

希望可以推動 Firefox 快一點支援... (這是養大 pool 的下一步)

ChaCha20-Poly1305 在 Android 上帶來的效能

Google 主推的 ChaCha20-Poly1305Android 上的 Chrome 可以看出顯著的效能差異:「Speeding up and strengthening HTTPS connections for Chrome on Android」。

在加密速度上與 AES-GCM 的差異:

AES-GCM 畢竟是標靶,被打爆本來就是預期中的事情,在 Google 大力推動下,應該是還蠻有機會成為主流...

不過隔壁棚好像還是沒什麼進展,不知道要等到何時:「Bug 917571 - Support ChaCha20+Poly1305 cipher suites」。

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 的原因,主要是速度考量。兩者的速度差非常多...