BoringSSL 的 FIPS 140-2 驗證

看到由 Google 主導的 BoringSSL 有計劃將其中一塊申請 FIPS 140-2 的驗證計畫 (BoringCrypto 的部份):「FIPS 140-2」。

其中 FIPS 140-2 最有名的後門應該是 Dual_EC_DRBG (定義於 NIST SP 800-90A,被 FIPS 140-2 引用),所以特地講清楚他們選擇哪個演算法:

FIPS 140-2 requires that one of its PRNGs be used (which they call DRBGs). In BoringCrypto, we use CTR-DRBG with AES-256 exclusively and RAND_bytes (the primary interface for the rest of the system to get random data) takes its output from there.

而且還花了不少篇幅解釋 PRNG 的細節。

AES-GCM-SIV

在「AES-GCM-SIV: Specification and Analysis」這邊看到 AES-GCM-SIV 的作者自己投稿上去的資料,是個已經被放進 BoringSSL 並且在 QUIC 上使用的演算法:

We remark that AES-GCM-SIV is already integrated into Google's BoringSSL library \cite{BoringSSL}, and its deployment for ticket encryption in QUIC \cite{QUIC} is underway.

在 RFC 上的說明解釋了這個演算法的目的是希望當 nonce 沒有被正確實作時仍然可以有比 AES-GCM 強的保護:

This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated.

在 128 bits 的情況下,加密的速度大約是 AES-GCM 的 2/3 (在都有硬體加速的情況下),但解密的速度則與 AES-GCM 相當:

For encryption, it is slower than AES-GCM, because achieving nonce-misuse resistance requires, by definition, two (serialized) passes over the data. Nevertheless, optimized implementations run GCM-SIV (for 128-bit keys) at less than one cycle per byte on modern processors (roughly 2/3 of the speed of nonce-respecting AES-GCM). On the other hand, GCM-SIV decryption runs at almost the same speed as AES-GCM.

不過這就是 trade-off 了,如果 nonce 有正確被實作的話,其實不需要這個...

Netflix 對 sendfile() 在 TLS 情況下的加速

Netflix 對於寫了一篇關於隱私保護的技術細節:「Protecting Netflix Viewing Privacy at Scale」。

其中講到 2012 年的 Netflix Open Connect 中的 Open Connect Appliance (OCA,放伺服器到 ISP 機房的計畫) 只有單台伺服器 8Gbps,到現在 2016 可以達到 90Gbps:

As we mentioned in a recent company blog post, since the beginning of the Open Connect program we have significantly increased the efficiency of our OCAs - from delivering 8 Gbps of throughput from a single server in 2012 to over 90 Gbps from a single server in 2016.

早期的 Netflix 走 sendfile() 將影片丟出去,這在 kernel space 處理,所以很有效率:

當影片本身改走 HTTPS (TLS) 時,其中一個遇到的效能問題是導致 sendfile() 無法使用,而必須在 userland space 加密後改走回傳統的 write() 架構,這對於效能影響很大:

所以他們就讓 kernel 支援 AES 系列加密 (包括 AES-GCM 與 AES-CBC),效能的提昇大約是 30%:

Our changes in both the BoringSSL and ISA-L test situations significantly increased both CPU utilization and bandwidth over baseline - increasing performance by up to 30%, depending on the OCA hardware version.

文章開頭也有提到選 AES-GCM 與 AES-CBC 的一些來龍去脈,主要是 AES-GCM 的安全強度比較好,另外考慮到舊的 client 不支援 AES-GCM 時會使用 AES-CBC:

We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-CGM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously - as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method.

另外 OCA 機器本身也都夠新,支援 AES-NI 指令集,效能上不是太大的問題:

All revisions of Open Connect Appliances also have Intel CPUs that support AES-NI, the extension to the x86 instruction set designed to improve encryption and decryption performance. We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L).

不過在「Netflix Open Connect Appliance Deployment Guide」(26 July 2016 版) 這份文件裡看起來還是用多條 10Gbps 透過 LACP 接上去:

You must be able to provision 2-4 x 10 Gbps ethernet ports in a LACP LAG per OCA. The exact quantity depends on the OCA type.

可能是下一版準備要上 40Gbps 或 100Gbps 的準備...?

Google 也 fork 一個 OpenSSL 出來了... (BoringSSL?)

Google 也跳下去 fork 一個 OpenSSL 出來了,這次的主力是放在 Android 以及 Chrome 上:「BoringSSL」。

BoringSSL 是暫時性的名稱,不過在「boringssl - Git at Google」這邊已經用這個名稱了...

另外一個重要的說明是 license 的部份:

We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.

將會改用 ISC license