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

Amazon Redshift 可以讀 S3 裡被 KMS 加密過的資料了

清資料時發現支援了:「Amazon Redshift now supports encrypting unloaded data using Amazon S3 server-side encryption with AWS KMS keys」:

The Amazon Redshift UNLOAD command now supports Amazon S3 server-side encryption using an AWS KMS key.

這樣資料丟上 Amazon S3 時可以透過 AWS KMS 加密保存,而 Amazon Redshift 可以透過 KMS 直接拉出來,處理起來會方便不少...

不過 Amazon Athena 好像還是沒辦法?

Google Cloud Platform 提供 Cloud Key Management Service

GCP 提供 Cloud Key Management Service (目前是 beta),將對 key 的處理 (像是加解密) 變成服務的一部分。

費用的部份,比較大的量應該會在「Key use operations (Encrypt/ Decrypt)」這塊?每一萬次收 USD$0.03。


前陣子在 Black Hat 上發表的 HEIST 攻擊 (對 HTTPS 的攻擊)

又是一個對 HTTPS 的攻擊:「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。

一樣是 Compression 產生的 side-channel attack,只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。

這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量,然後從旁邊看 HTTPS 連線的 TCP packet 就可以了,而且對 HTTP/2 也很有效:

而且很不幸的,目前沒有太好的解法,因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@

對於使用者,大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件),能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線,產生 HTTPS 的行為。

而對於網站端來說,全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做,可以透過 apache module 或是 nginx module 做到),但還是可以被統計方法再推算出來。

不知道有沒有辦法只對 HTTPS 開 javascript,雖然攻擊者還是可以用 <img> 攻擊...

也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的,避開這類 compression-based attack @_@

CIA 老大告訴參議員,在加密系統裡放後門是可行的,因為沒有公司可以逃離美國魔掌

如同標題講的,CIA 老大 John Brennan 告訴參議員,因為實務上不存在「Non-US encryption」,所以強制任何要進入美國的企業使用美版帶有後門的加密系統是可行的:「Non-US encryption is 'theoretical,' claims CIA chief in backdoor debate」。

CIA director John Brennan told US senators they shouldn't worry about mandatory encryption backdoors hurting American businesses.

And that's because, according to Brennan, there's no one else for people to turn to: if they don't want to use US-based technology because it's been forced to use weakened cryptography, they'll be out of luck because non-American solutions are simply "theoretical."

這位腦袋已經壞掉了啊,你知道有個叫做 China,拼做 C-h-i-n-a 的經濟體系嗎... 然後中美共用同一套有後門的加密系統瞬間就會被一堆人打槍,如果真的發生,還有個歐盟... 而且這些事情只是促進以色列的安全系統加速脫離美國掌控啊?以色列才是目前資安的超級強國啊...


Google 刻意讓 Allo 不安全的方法

兩篇文章與一則 tweet 剛好可以一起看。

兩篇文章分別是「Don't Use Allo」講 Google Allo 預設沒有加密的問題,與「How Technology Hijacks People’s Minds — from a Magician and Google’s Design Ethicist」講如何設計產品來改變人的行為。

在市場上的領先者 Whatsapp 已經啟用預設 end-to-end encryption 後,Google Allo 之所以不是預設加密的原因,是基於這樣的設計方法,因為 Google 並不想要加密:

Businesses naturally want to make the choices they want you to make easier, and the choices they don’t want you to make harder. Magicians do the same thing. You make it easier for a spectator to pick the thing you want them to pick, and harder to pick the thing you don’t.

而這則 tweet 剛好解釋了這個方法背後幾個可能的利害關係,大公司受到政府單位的施壓而妥協:


Amazon Fire 會把加密系統弄回來

FBIApple 的戰爭開打後,愈來愈多安全與隱私問題被重新拿出來檢驗,而 Amazon 也決定將 2015 年拔掉的加密功能搬回 Fire OS 裡:「Amazon Reverses Course, Encryption Returning for Fire Devices」: Inc. will restore encryption as a security option on its tablets and other devices that use the Fire operating system, following a customer backlash driven by increased sensitivity about data protection as Apple Inc. grapples with the FBI over access to a terrorist’s iPhone.


Amazon reversed course late Friday night, saying in an e-mail that it would restore encryption as an option on Fire devices with a software update “this spring,“ without being more specific.



在「Thousands of apps running Baidu code collect, leak personal data - research」這篇裡,加拿大的研究團隊 Citizen Lab 發現百度的 Android SDK 使用非加密傳輸這些個資:

The unencrypted information that has been collected includes a user's location, search terms and website visits, JeffreyKnockel, chief researcher at Citizen Lab, told Reuters ahead of publication of the research on Wednesday.


[,] and Baidu told Reuters it would be fixing the encryption holes in its kits, but would still collect data for commercial use, some of which it said it shares with third parties.

霸氣!不愧是百度!即使被抓到後還是要蒐集 XDDD

GitHub 的 SSL (HTTPS) 也支援 PFS 與 AE 了...

GitHub 在 2013 年底的公告:「Introducing Forward Secrecy and Authenticated Encryption Ciphers」。

愈來愈多服務升級 & 調整 SSL (HTTPS) 的設定,支援 PFS (Perfect Forward Secrecy) 與 AE (Authenticated Encryption)。

PFS 要預防的事情我可以理解,但對 AE 的必要性不熟啊... 再去看看整個理論基礎與目的好了...

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1連結2)

OpenSSLGnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...