Tag: number

四位數密碼的分佈

分析信用卡四位數密碼的分佈：「PIN number analysis」。

透過已經外洩的資料分析：

Obviously, I don’t have access to a credit card PIN number database. Instead I’m going to use a proxy. I’m going to use data condensed from released/exposed/discovered password tables and security breaches.

19xx 那邊特別高，拉出來看可以看到分佈：(很像是出生年 XDDD)

相同的 abab (前兩碼與後兩碼相同) 也可以看出特別高，而 aaaa (四碼都一樣) 的特別亮：

當不只四碼時，也有一些數據：

另外是特別高的 1004 的原因：

Many people also asked the significance of 1004 in the four character PIN table. This comes from Korean speakers. When spoken, "1004" is cheonsa (cheon = 1000, sa=4).

"Cheonsa" also happens to be the Korean word for Angel.

V8 Engine 的 Math.random() 在新版被重寫了...

先前在「V8 的 Math.random() 亂度不足的問題」提到 Math.random() 因為使用 MWC1616 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines) 而不夠亂的問題。

這個問題在新版 V8 Engine 提出改善了：「There's Math.random(), and then there's Math.random()」。

Untitled drawing

新實作的方法是 xorshift128+，擁有極長的 period length：

This has been pointed out to us, and having understood the problem and after some research, we decided to reimplement Math.random based on an algorithm called xorshift128+. It uses 128 bits of internal state, has a period length of 2128 - 1, and passes all tests from the TestU01 suite.

將會在 Google Chrome 49 (目前是 47) 引入：

The new implementation landed in V8 4.9.41.0 within a few days of us becoming aware of the issue. It will become available with Chrome 49. Both Firefox and Safari switched to xorshift128+ as well.

同時還是再次提醒，這不是 CSPRNG，要用在密碼學相關應用還是要用專門的 library 來產生 pseudo random number：

Make no mistake however: even though xorshift128+ is a huge improvement over MWC1616, it still is not cryptographically secure.

V8 的 Math.random() 亂度不足的問題

在「TIFU by using Math.random()」這篇看到作者踩到地雷，於是在討論 V8 Engine 的 Math.random() 的亂度不足。

其實這個問提早在 2012 年就有人在 StackOverflow 上詢問：「Why is Google Chrome's Math.random number generator not *that* random?」，而且也回答得很清楚。

而 Mozilla 這邊在 2006 年也被提出了類似的問題：「Bug 322529 - Upgrade Math.random() to a better algorithm, such as Mersenne Twister」。

文章中間花了許多篇幅講 PRNG 的介紹，以及 cycle length 的說明，重點其實在結論的部份。

主要是因為 V8 Engine 的 Math.random() 實作的是 MWC1616 演算法 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines)，而這個演算法用起來也綁手綁腳：

If you’re only using the most significant 16 bits it has a very short effective cycle length (less than 2³⁰).

有兩個方向可以改善 (不衝突的方向)，一個是使用 CSPRNG (保證有極長的 cycle length)，另外一個請求 V8 Engine 把 Math.random() 的演算法換掉，像是 MT19937 這類 cycle length 超級長的演算法。

不知道後續有沒有機會改善...

利用 WPS 實做上的問題攻擊，而取得 WPA 密碼

在「Wi-Fi Router Attack Only Requires a Single PIN Guess」這邊看到利用 WPS 實做上的弱點攻擊而取得 WPA 的密碼。

投影片取自「Offline bruteforce attack on WiFi Protected Setup」這邊：

利用各種方法攻擊，像是不夠安全的 PRNG (Pseudo Random Number Generator)。

作者的建議是，關掉 WPS 會比較安全 XD

利用 Facebook Notes 對圖片 cache 的特性發動 DDoS 攻擊

在「Using Facebook Notes to DDoS any website」這篇文章裡提到了利用 Facebook Notes 允許使用者嵌入 <img> 標籤時的特性，利用 Facebook 的 server 進行 DDoS...

在 Notes 一般的 <img> 會被 Facebook 的伺服器 cache 起來，但如果是帶有 query string 的 <img> 就不會 cache (因為不同的 query string 表示不同的 url 是合理的)，於是就可以利用這個特性打出超高的流量：

這個問題被 Facebook 認為不是問題，不會也不打算修正...

文章後提到的指令還蠻有趣的，要抓出某個 AS number 有哪些 IP address，可以用這樣的指令抓出來：

whois -h whois.radb.net — '-i origin AS32934' | grep ^route

試著抓了 AS9916 與 AS18185，的確是蠻有趣的東西 XD

NSA 付錢給 RSA 放後門的事件...

Edward Snowden 再次丟出 NSA 內部文件，表示 NSA 付錢給 RSA 在演算法裡面放後門：「Exclusive: Secret contract tied NSA and security industry pioneer」。

RSA 的回應則是完全不想提到這筆錢是做什麼用的：「RSA Response to Media Claims Regarding NSA Relationship」。

現在一般在猜測，這個後門應該就是 RSA BSAFE 的預設偽隨機數產生器 Dual_EC_DRBG。

對於 Dual_EC_DRBG 的攻擊，2006 年的「Cryptanalysis of the Dual Elliptic Curve Pseudorandom Generator」就這樣寫：

Our experimental results and also empirical argument show that the DEC PRG is insecure. The attack does not imply solving the ECDLP for the corresponding elliptic curve. The attack is very efficient.

在 2007 年，Bruce Schneier 寫了一篇「Did NSA Put a Secret Backdoor in New Encryption Standard?」，提到這個弱點並沒有大到使得這個演算法不堪用，但看了總是不爽：

Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn't large enough to make the algorithm unusable -- and Appendix E of the NIST standard describes an optional work-around to avoid the issue -- but it's cause for concern. Cryptographers are a conservative bunch: We don't like to use algorithms that have even a whiff of a problem.

並且建議不要用 Dual_EC_DRBG：

My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

現在回頭看這件事情... hmmm...

對 /dev/random 的攻擊...

Bruce Schneier 的 blog 上寫了一篇「Insecurities in the Linux /dev/random」，針對 /dev/random 的亂度找出弱點攻擊，雖然目前的攻擊看起來影響不大...

論文被傳到 Cryptology ePrint Archive 上，名稱是「Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is not Robust」。

NSA 向世人展示了任何實做上的問題都可以成為漏洞的能力，這些純理論的研究也愈來愈被重視...