Let's Encrypt 支援 IDN

Let's Encrypt 宣佈支援 IDN:「Introducing Internationalized Domain Name (IDN) Support」,這代表可以申請的範圍變得更廣了:

This means that our users around the world can now get free Let’s Encrypt certificates for domains containing characters outside of the ASCII set, which is built primarily for the English language.

在「Upcoming Features」可以看到下一步應該是 ECDSA Intermediates?

Let’s Encrypt only signs end-entity certificates with RSA intermediates. We will add the ability to have end-entity certs signed by an ECDSA intermediate.

不曉得之後還會有什麼功能...

Google Chrome 引入 CECPQ1,開始測試 Post-Quantum Cryptography

Quantum Computer 對現有密碼學的衝擊很大,像是 RSA 演算法是基於「質因數分解」的難題而架構出來的系統,在 Quantum Computer 上存在有效率的演算法,也就是 Shor's algorithm

雖然 Quantum Computer 在技術上還沒辦法對現有演算法造成有效的攻擊,但已經有人提出新的演算法來對抗,而 Google 打算在 Google Chrome 裡面引入測試:「Experimenting with Post-Quantum Cryptography」。

Google 也特別說明了,他們不希望這個實驗最後變成 de-facto standard (借測轉出貨的概念),而是希望當作一個開頭,希望之後可以用更好的標準換掉:

We explicitly do not wish to make our selected post-quantum algorithm a de-facto standard. To this end we plan to discontinue this experiment within two years, hopefully by replacing it with something better.

密碼系統的 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

USD$75 解 RSA 512bits

Cryptology ePrint Archive 上面剛好是 2015 年編號 1000 號的論文:「Factoring as a Service」。透過 Amazon EC2 服務以及 CADO-NFS 的幫助,四小時內就可以解出 512bits RSA,而如同作者說的,雖然已經很不安全了,但在許多地方仍然被使用著:

The difficulty of integer factorization is fundamental to modern cryptographic security using RSA encryption and signatures. Although a 512-bit RSA modulus was first factored in 1999, 512-bit RSA remains surprisingly common in practice across many cryptographic protocols. Popular understanding of the difficulty of 512-bit factorization does not seem to have kept pace with developments in computing power. In this paper, we optimize the CADO-NFS and Msieve implementations of the number field sieve for use on the Amazon Elastic Compute Cloud platform, allowing a non-expert to factor 512-bit RSA public keys in under four hours for $75. We go on to survey the RSA key sizes used in popular protocols, finding hundreds or thousands of deployed 512-bit RSA keys in DNSSEC, HTTPS, IMAP, POP3, SMTP, DKIM, SSH, and PGP.

另外也有專案網站:「Factoring as a Service」,程式碼也有放上 GitHub:「Factoring as a Service」。

Let's Encrypt 建立 Root Certificate 與 Intermediate Certificate

Let's Encrypt 的 Root Certificate 與 Intermediate Certificate 建出來了:「Let's Encrypt Root and Intermediate Certificates」。

Intermediate Certificate 除了會讓自己的 Root Certificate 簽名外,也會讓 IdenTrust 的 DST Root CA X3 簽 (目前各大瀏覽器與 SSL library 都有支援)。

目前是 RSA key,之後會生出 ECDSA key:

All ISRG keys are currently RSA keys. We are planning to generate ECDSA keys later this year.

對 GitHub 的 Public Key 分析

Hacker News Daily 上看到有人針對 GitHub 上的 Public Key 分析:「Auditing GitHub users’ SSH key quality」。

這個分析主要用的是 GitHub 的 .keys 功能取得:

A little known feature of GitHub is the ability to look at the public SSH keys that other users have set to be authorised on their account (for example https://github.com/torvalds.keys)

作者從去年 2014 年 12 月 27 日跑到今年 2015 年 1 月 9 日,共取得了 1376262 把 public key,然後就針對這些 key 分析。

「The Debian bug bites again」這一段講的是 CVE-2008-0166 (可以參考「該換 ssh keys 了」這篇的說明),發現即使是七年後的現在,也還是有問題。

另外還有 256 bits 與 512 bits 的 RSA key,作者自己建立了一把測試,用 i5-2400 只要 25 分鐘就可以解出 256 bits 的 private key:

This risk isn’t only real if someone had gathered together top of the line mathematicians or supercomputers worth of power, the 256 bit key I factored was factored on a i5-2400 in 25 mins.

NSA 應該都摸透了...

作者提供的時間線:

[27th December 2014] Key Crawl Started
[28th Feb 2015] Disclosed low bits issue to a peer at GitHub
[1st March 2015] Discovered the weak Debian Keys (and disclosed)
[5th May 2015] Debian keys revoked, emails sent out
[1st June 2015] Weak and low quality keys revoked

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.

RSA Conference 2015 禁止 Show Girl

前幾天的消息:「RSA Conference Bans "Booth Babes"」。報導出自於「RSA Conference bans ‘booth babes’」。

規範的文字:

All Expo staff are expected to dress in business and/or business casual attire. Exhibitors should ensure that the attire of al staff they deploy at their booth (whether the exhibitor’s direct employees or their contractors) be considered appropriate in a professional environment. Attire of an overly revealing or suggestive nature is not permitted. Examples of such attire may include but are not restricted to:

  • Tops displaying excessive cleavage;
  • Tank tops, halter tops, camisole tops or tube tops;
  • Miniskirts or minidresses;
  • Shorts;
  • Lycra (or other Second-Skin) bodysuits;
  • Objectionable or offensive costumes.

These guidelines are applicable to all booth staff, regardless of gender, and will be strictly enforced. We reserve the right to request that individual booth staff change their attire or leave the premises immediately if we feel their appearance might be offensive to other exhibitors or attendees.

讓我想起 2009 年 Yahoo! 辦的 Taiwan Open Hack Day:「Yahoo Sorry About Lap Dancers at Hack Day in Taiwan–So What's the Excuse for Last Year's Go-Go Girls?」。

CloudFlare 的 Keyless SSL 服務

CloudFlare 有兩篇公告出來:「Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys」、「Keyless SSL: The Nitty Gritty Technical Details」。前面的一篇偏向公告文 (以及公關稿),而後面的一篇提到了實際運作的方式。

用兩張 Keyless SSL 的 flow 就可以知道差異了,一張是 RSA-based,一張是 DH-based:

把與 private key 相關的運算拆出來,由後方計算完成後再計算出 session key 與 client 溝通。如此一來,雖然速度比較慢,但 private key 管理在客戶自己手上...

很特別的 Side-channel attack 方法以取得 RSA 與 ElGamel 的 private key

在「A new Side channel attack-how to steal encryption keys by touching PCs」這邊看到一種很特別的 side-channel attack:(直接先看圖)

引用說明:

The signal can also be measured at the remote end of Ethernet, VGA or USB cables.

方法愈來愈特別了 XDDD