DeepMind 的 Player of Games

前幾天在 Hacker News Daily 上看到的消息,DeepMind 發了一篇新的論文,講 Player of Games 這個新的演算法:「Player of Games」,Hacker News 上的討論在這:「Player of Games (arxiv.org)」。

照留言上的討論,Player of Games 的名字由來應該是取自科幻小說《The Player of Games》。

這是一個更一般性的演算法,可以同時駕馭 perfect information 與 imperfect information:

We introduce Player of Games, a general-purpose algorithm that unifies previous approaches, combining guided search, self-play learning, and game-theoretic reasoning. Player of Games is the first algorithm to achieve strong empirical performance in large perfect and imperfect information games -- an important step towards truly general algorithms for arbitrary environments.

論文裡面也提到以前的各種演算法 (包含 DeepMind 自家的一些演算法)。在 perfect information 的例子來說,可以看到沒有 AlphaZero 強 (西洋棋與圍棋),但也已經有一定水準了,算是個起頭的感覺:

主要的成就在於一般性,但論文後面也有提到,目前這個演算法需要的資源還是過大,還有改善的空間...

兩個 gperf...

翻資料的時候覺得怎麼跟印象中的不太一樣,多花些時間翻了一下,發現原來有兩個東西同名...

一個是 GNUgperf,給定字串集合,產生 C 或 C++ 的 perfect hash function (i.e. no collision):

GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.

另外一個是 Google 弄出來的 gperftoolsmalloc() 的替代品以及效能分析工具:

gperftools is a collection of a high-performance multi-threaded malloc() implementation, plus some pretty nifty performance analysis tools.

在 SSL Labs 上拿到 Perfect Score (完全滿分的 A+)

在「Achieving a Perfect SSL Labs Score with Go」這邊提到要如何在 Go 上面達到 SSL LabsSSL Server Test 的 Perfect Score (完全滿分的 A+),但其實裡面大多數的東西都應該適用於其他地方。

其中 Cipher Strength 這邊讓人非常意外的是,只有在關閉 HTTP/2 的情況下才有可能達到 100%,因為 HTTP/2 規定強制要支援 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,而這是 128bits cipher,會導致無法達到 100%:

No HTTP/2 for you! - HTTP/2 was enabled by default in go 1.6, however HTTP/2 mandates the support of the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. As this is a 128bit cipher, it needs to be removed. The only way to achieve a perfect score now is to disable HTTP/2.

這被點出來後不知道會有什麼改變... (無論是 HTTP/2 或是 SSL Labs)

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...

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 的必要性不熟啊... 再去看看整個理論基礎與目的好了...

Twitter 也要上 PFS 了...

Twitter 宣佈他們的 HTTPS 連線要上 PFS (Perfect Forward Secrecy) 了:「Forward Secrecy at Twitter」。

回頭查了 F5 要到哪個版本才支援 PFS,看起來要 11.2.1 之後的版本有支援... (出自「BIG-IP LTM and TMOS 11.3.0」這份文)

目前有一組已經是 11.2.1 之後的版本,這樣看起來好像也可以開看看?

SSL/TLS 的 Perfect Forward Secrecy...


寫這篇順便測試 MathJax 的效果...

因為 NSA 的惡搞,這陣子 PFS (Perfect Forward Secrecy) 突然被拿出來討論:

在講 PFS 前,得先講 Diffie-Hellman key exchange (D-H)。

D-H 是利用這個等式:

$$(g^a)^b \equiv (g^b)^a \mod p$$

其中 \(p\) 是大質數,而 \(g\) 是 \(p\) 的 primitive root (即不存在任何 \(n < p\) 可以使得 \(g^n \equiv 1 \mod p\))。 而因為當 \(p\) 夠大時,要從 \(g^a \mod p\) 計算 \(a\) 就是離散對數問題,而離散對數問題是已知沒有有效率計算的問題,所以我們會假定當 \(p\) 夠大時,傳輸 \(g^a \mod p\) 是無法用合理資源計算得知 \(a\)。

因此,Alice 與 Bob 就可以產生自己的 private secret \(a\) (Alice) 與 \(b\) (Bob),計算出 \(g^a\) 與 \(g^b\) 後公開傳輸給對方,當 Bob 收到 Alice 提供的 \(g^a\) 時就計算 \((g^a)^b \equiv g^{ab} \mod n\),而 Alice 收到 Bob 提供的 \(g^b\) 後可以計算 \((g^b)^a \equiv g^{ba} \equiv g^{ab} \mod n\)。

而攻擊者只拿到公開的 \(g^a\) 與 \(g^b\) 以及 \(g\),無法計算出 \(g^{ab}\),於是就雙方就建立一組 shared secret 了。

回到 SSL/TLS 的問題上,由於 RSA 加解密的速度並不快,所以 SSL/TLS 是在 RSA 的保護下交換 RC4 或是 AES 所需要的金鑰 (key)。

交換 key 這件事情除了可以直接交換以外,還可以利用 D-H 交換。

D-H 交換可以確保當 RSA key 被破解時還要再破每個 session 的 D-H 所產生出來的 key,而直接交換的話,只要破一把 RSA key 就可以解出所有 traffic 了。

而 PFS 會被提出來,是因為目前消息指出 NSA 其實有在錄下 SSL/TLS 流量,等哪天有機會取得 RSA key 的時候 (無論是硬解,或是其他方式),就有機會能夠一次破一卡車資料... (因為目前大部分的 SSL/TLS 流量都沒有上 PFS)

雖然 PFS 會慢一些,不過已經確認 NSA 打算來搞了,所以還是乖乖加上去吧... @_@