Quantcast
Channel: aes – Gea-Suan Lin's BLOG
Viewing all 36 articles
Browse latest View live

SHA-3 最後審查…

$
0
0

Schneier on Security 上看到 SHA-3 的消息:「SHA-3 to Be Announced」。

1997 年,NIST 要找尋 Data Encryption Standard (DES) 的下一代標準,發起了有名的 AES 遴選計畫,也就是 Advanced Encryption Standard process

公開遴選 AES 的成果就是在 2001 年 NIST 選出 Rijndael,由 Vincent RijmenJoan Daemen 兩位比利時密碼學家所發展出的對稱式加密系統。這個成果以現在來看是相當受到好評的:從 1998 年 Rijndael 問世到現在已經將近 15 年,成為官方標準後也超過 10 年,在這麼長時間接受全世界密碼學家檢驗後,有效的攻擊 (full cycle,可以破解實際流量的演算法) 是 2009 年一系列針對 192bits 與 256bits 的攻擊 (Related-key attack),以及 2011 年針對所有 128bits/192bits/256bits 的攻擊 (Key-recovery attack),仍然都還不到「實用」的程度 (用合理的硬體與資源破解)。

因此,當 MD5SHA-1 被攻的亂七八糟時 (2004 年王小雲教授往 ePrint 上丟出有名的「Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD」論文,給出兩個 vector 直接給出證明已經找到 collision),NIST 也想要透過同樣的遴選過程建立標準。於是,在 2007 年 NIST 宣佈了遴選計畫,這套標準就叫做 SHA-3,遴選過程則可以在 NIST hash function competition 這邊查到。

歷經五年的競爭,SHA-3 終於要宣佈結果了… (也有可能宣佈「沒有得主」?)

Related Posts:


把 SSH 換成 Mosh

$
0
0

Mosh 是一個取代 SSH (OpenSSH) 的工具,官方網站上是這樣介紹:

Mosh is a replacement for SSH. It’s more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh 最大的特性是透過 UDP 加密傳輸 (AES-128 OCB mode),而且不綁定 IP address 後設計出這些特性:

  • 筆電休眠後再打開電腦就可以直接連上。
  • 登入 VPN 造成 IP 改變後也沒關係。

另外 Mosh 模擬了 local echo 機制,就算在 latency 偏高的網路下也還是可以感覺到不錯的反應速度。

不過是到了 1.2 之後支援 --ssh 這個參數才變得好用,在 client 端只要這樣跑 (假設 ssh port 在 1234):

mosh --ssh="ssh -p 1234 -v" gslin@server.example.com --server="env LANG=en_US.UTF-8 mosh-server"

Mosh 就會用 ssh 登入後自動執行 mosh-server 取得 shared key 給 mosh-client 用。如果本來就有使用 public key 機制的話就跟原來沒差了 :p

預設吃 port 60000-61000 其中的一個 UDP port,所以記得開 firewall…

Related Posts:

加快 SSL 加解密速度…

$
0
0

看到 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 一般的情況下看起來沒得用,所以就自己取捨啦…

Related Posts:

手機網路的不安全性…

$
0
0

在整理舊文章的時候看到有人對 GSM 網路以及 3G/LTE 網路的安全性進行分析:「On cellular encryption」。

2G 網路 (GSM 網路) 已經是不安全的架構,主因是 30 年前可用的技術受限,加上當時的美國法令嚴格管制加密技術出口,所以整個通訊協定放了一堆後門…

3G 網路建立時 AES 也還沒出來 (1998 年 NTT DoCoMo 建立第一個非商用性質的 3G 網路),當時選用的 KASUMI cipher 後來被打趴好幾次…

4G/LTE 用的技術就更新了,當然是另外的故事,不過還是把手機網路當作不安全的媒介會比較好…

因為 NIST 而換掉 AES?

$
0
0

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 會比較安全嗎?

Related Posts:

OpenSSH 安全性問題…

$
0
0

Twitter 上看到 Gasol 轉推的 OpenSSH 安全性問題:「OpenSSH Security Advisory: gcmrekey.adv」。

開頭就直接寫:

If exploited, this vulnerability might permit code execution with the privileges of the authenticated user and may therefore allow bypassing restricted shell/command configurations.

這噴飯了… OpenSSH 的安全性相當強,這次出這種包… XDDD

影響的範圍是 OpenSSH 6.2 與 6.3,並且 OpenSSL 有編 AES-GCM:

OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.

如果不允許升級到 OpenSSH 6.4,那麼暫時性的解法是不允許 AES-GCM,在 /etc/ssh/sshd_config 內可以設:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

結果 FreeBSD 9.2 看起來在範圍內中槍,先上 workaround 再來等 freebsd-update 提供的修正吧…

Related Posts:

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

$
0
0

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

Related Posts:

FreeBSD 對 OpenSSH 的安全性更新…

$
0
0

讓我意外的是,只有 FreeBSD 10.0-BETA (還沒出 RELEASE 的版本) 有問題,9.2-RELEASE 並不在內:「OpenSSH AES-GCM memory corruption vulnerability」。

本來 9.2 的機器有上 workaround 把 AES-GCM 強制拔掉,看起來可以 revert 回來了…

Related Posts:


ChaCha20-Poly1305 將被移植到 OpenSSH 上…

$
0
0

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 企圖同時解決這兩個問題,接下來就是看時間考驗了…

Related Posts:

MySQL 5.7.4

$
0
0

在「The MySQL 5.7.4 Milestone Release is available」這篇可以看到 MySQL 5.7.4 的消息。除了 InnoDB 的改善外,可以看到對 AES 加密的功能 (AES Encryption Modes)。

不過…

Historically, and still used as defaults in 5.6 and 5.7, we are using a relatively small key size (128 bits, corresponding to “SECRET” according to NSA) and block mode (ECB, encrypting equal blocks with equal code blocks) to calculate the cipher.

居然是支援 ECB,這會不會驚爆我的眼球啊,我以為最少是 CTR

ECB 代表相同內容的 block 就會被加密成相同的密文,這樣就有很多可以攻擊的方式了。而 CTR 至少可以抵抗這一點…

另外一個賣點是「InnoDB Spatial Indexes in 5.7.4 LAB release」,目前只支援二維資料:

Currently, InnoDB spatial index supports only two dimension data, but we do have plan to extend to multi-dimension. In addition, we are doing more performance tuning to make it more efficient.

R-tree 實做的,畢竟是個開始…

Related Posts:

ChaCha20-Poly1305 在 Android 上帶來的效能

$
0
0

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」。

Related Posts:

CloudFlare 停用 RC4 後的現象,以及後續…

$
0
0

今年一月的時候 CloudFlare 宣佈針對使用 TLS 1.1+ 的使用者停用 RC4:「Killing RC4 (softly)」。

而現在 (五月) 則直接從 cipher priority 上拔掉 RC4:「Killing RC4: The Long Goodbye」。

切換後的資料其實非常有趣:

可以看到本來用 RC4 的有兩塊,一塊是 ECDHE-RC4,一塊是 RSA-RC4。在 RC4 被拿掉後,就流竄到 ECDHE-AES-CBC 與 RSA-AES-CBC… (這兩個本來就可以預期)

但冒出 RSA-3DES 是怎樣 XDDD

Anyway,CloudFlare 在目前市場上算是很大的 provider,由他們出面率先拔掉 RC4 會對整個市場有正面的影響。接下來看看還有誰會動手?

Related Posts:

JPEG 用 AES-CBC 加密後變成 PNG,用 3DES-CBC 解密後變成 PDF…

$
0
0

直接練出一份 PoC 讓大家看:「a JPEG that becomes a PNG after AES encryption and a PDF after 3DES decryption」,這是原始檔:(這邊直接引用 Google Code 上的 image)

透過 AES-CBC 加密後會是這樣的圖片:

透過 3DES-CBC 解密後則是這樣的 PDF:


Related Posts:

選擇 OpenSSL Cipher 時的參考資料

$
0
0

Qualys SSL Labs 在「User Agent Capabilities」有提供不少好用的資料,其中每個 client 點進去以後就可以知道支援哪些 cipher,像是「User Agent Capabilities: Android 2.3.7」這頁裡面可以看到只支援 SSLv3 以及 TLSv1,而支援的 cipher 大多都比較弱一點 (3DES 的 112bits 以及 RC4/AES 128bits 為主):

就用這些資訊去湊,設上去後再實際測試 :o

Related Posts:

NCCC (聯合信用卡處理中心) 的網站不支援 AES 加密...

$
0
0

看到廉價航空機票在特價跑去刷,結果刷了兩次都死在聯合信用卡處理中心的 acs.nccc.com.tw 畫面出不來。突然想到我把 RC4 關掉了,該不會是這種原因吧...

跑去「SSL Report: acs.nccc.com.tw (210.61.215.16)」這邊一看,果然是不支援 AES

抱頭痛哭啊... 只好 rollback 回來 @_@

Related Posts:


用 Go 寫的 Tor Relay Server

$
0
0

Zite 上看到的「Implementing a Tor relay from scratch」,用 Go 寫的 Tor Relay Server。

會跳下去用 Go 寫是因為效能上的考量:

[...], but the lack of AES-NI instructions on the CPUs cause a significant slowdown.

但因為一個 IP 只能跑兩個 instance,這就有點痛了:

To maximize the amount of relayed data, it is normal to simply run multiple instances of the program, up to two per IP address.

而作者的目標是超過現有的極限:

My final goal was to beat the Tor speed record, which was at roughly 200 megabytes per second.

成果就是直接吃滿 2Gbps (250MBytes/sec),而且 CPU 只用了 60%:

[...] He set up a server with my relay and within a few days we had broken the Tor speed record with a nice 250 megabytes per second, effectively maxing out the network link. CPU usage was at a nice 60% across 12 cores. But his relay also suffered from the memory issues and had to be restarted every few days.

作者的程式碼放在 GitHub 上,之後應該會有人跳進去改寫:「A fast implementation of the Tor OR code, in Go」。

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

$
0
0

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 的下一步)

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

$
0
0

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.

密碼系統的 Monoculture

$
0
0

這篇文章講到最近密碼系統的現象:「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

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

$
0
0

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 的準備...?

Viewing all 36 articles
Browse latest View live