Home » Posts tagged "aes"

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 而不會出現錯誤訊息,但暫時還不會有效果...

Intel 最新的 Ice Lake 系列對 AES 的加速

Twitter 上看到這篇,講 Intel 推出新的指令集,對 AES 的加速效果:

進去看以後發現是講四月推出的 Ice Lake,在上面新增的 VPCLMULQDQ 指令對效能的幫助:

The introduction of the processor instructions AES-NI and VPCLMULQDQ, that are designed for speeding up encryption, and their continual performance improvements through processor generations, has significantly reduced the costs of encryption overheads.

而他們發表出來的數據說 AES-GCM 的效率直接從 ~23 cycles/byte 降到 0.64 cycles/byte,大約是 35 倍的改進?

More and more applications and platforms encrypt all of their data and traffic. As an example, we note the world wide proliferation of the use of AES-GCM, with performance dropping down to 0.64 cycles per byte (from ~23 before the instructions), on the latest Intel processors.

就算不是 AES-GCM,而是其他的 AES 相關演算法,也是三倍以上的改善:

這效能差異...

DynamoDB 可以透過 KMS 加密了...

AWSDynamoDB 可以透過 KMS 加密了:「New – Encryption at Rest for DynamoDB」。

You simply enable encryption when you create a new table and DynamoDB takes care of the rest. Your data (tables, local secondary indexes, and global secondary indexes) will be encrypted using AES-256 and a service-default AWS Key Management Service (KMS) key.

看起來不是自己的 KMS key,而是 service 本身提供的,這樣看起來是在 i/o level 加密,所以還不是 searchable encryption 的能力...

最新的 Firefox 56 對 AES-GCM 效能的改善

昨天釋出的 Firefox 56 對於 AES-GCM 在老電腦上改善了不少效能:「Improving AES-GCM Performance」。

首先是 Firefox 自己的數據分析,可以看到 AES-GCM 佔目前加密連線裡的大宗,再來是 AES-CBC:

先以 Linux 64bits 環境的數據來看,Firefox 56 的 NSS 3.32 大幅改善了老電腦的效能 (不支援 AES-NI 硬體加解密的 CPU,甚至是不支援 PCLMUL 的 CPU,以及不支援 AVX 的 CPU):

在 Linux 32bits 環境上則是連預設值大幅改善,不過用的人應該少很多了:

Windows 下則是因為 64bits 或是 32bits 都有足夠的使用者,所以平常就花了不少力氣。但也可以看出對於老電腦的速度提升:

Mac (64bits only) 算是這次比較大的提升,連新電腦的預設值都大幅變快:

加上之後陸續的改善 (尤其是下一版 Firefox 57 的 Project Quantum),這幾版應該會拉出不少效能...

Telegram 使用 CDN 加速下載

Telegram 說明他們將會使用 CDN 加速:「More Speed and Security!」。

資料在 CDN 的節點上是加密的,金鑰需要透過 Telegram 的 key server 提供:

While these caching nodes are only used to temporarily store public media (imagine Telegram versions of superpopular YouTube hits), all data that goes through them is encrypted with a key unknown to the caching nodes. In other words, we treat these CDN caching nodes just like we treat your internet provider – they only ever get encrypted junk they can't decipher.

但這表示 Telegram 本身有能力解開這些資料?不知道這邊講的是什麼行為...

使用者如果選擇願意公開的話當然沒問題,但這種情況下也不需要 CDN 加密;而當使用者不願意公開時,應該是期望 Telegram 也無法解開這些資料?再來看看到底是怎麼樣的功能要上 CDN?

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 的細節。

手機上用 FPGA 的想法...

在「Apps with hardware: enabling run-time architectural customization in smart phones」這邊看到去年就有論文在討論在手機上使用 FPGA 的想法...

的確現在 FPGA 的價錢其實是蠻平價的了... 除了透過 GPU 加速外,FPGA 聽起來也是個不錯的方向 @_@

最直接的例子就是 AES 運算來看,可以看到比現在最快的實做快了半個數量級,大約三倍?(跟支援硬體加速的 OpenSSL 比,看格子大約是半格,也就是 100.5,約 3.16 倍)。

而如果是純軟體的應用,有些會差到四個數量級... (萬?)

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 的實做...

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 有正確被實作的話,其實不需要這個...

Dropbox 儲存密碼的方式

記得 Dropbox 前陣子才強迫所有使用者重設密碼:「The Dropbox hack is real」,官方的報告在這:「Resetting passwords to keep your files safe」,當時洩漏出來的資訊可以知道 2012 年的時候 Dropbox 用的是 SHA1:

What we've got here is two files with email address and bcrypt hashes then another two with email addresses and SHA1 hashes.

三個多禮拜候,Dropbox 說明了現在的密碼儲存策略:「How Dropbox securely stores your passwords」,現在是先 SHA512,再 bcrypt,然後存在資料庫裡時使用 AES256 保護:

比較特別一點的是先 SHA512 的部份,除了 72bytes 常見限制外,另外一個原因是為了避免 DoS,不過還是覺得有點怪就是了:

Other implementations don’t truncate the input and are therefore vulnerable to DoS attacks because they allow the input of arbitrarily long passwords.

而 AES256 的部份則是確保就算 SQL injection 或是其他方式將儲存的密碼撈出去後,也還有相當程度的保護能力。

Archives