Tag: dev

Linux 打算合併 /dev/random 與 /dev/urandom 遇到的問題

在 Hacker News 上看到「Problems emerge for a unified /dev/*random (lwn.net)」的，原文是「Problems emerge for a unified /dev/*random」(付費內容，但是可以透過 Hacker News 上的連結直接看)。

標題提到的兩個 device 的性質會需要一些背景知識，可以參考維基百科上面「/dev/random」這篇的說明，兩個都是 CSPRNG，主要的分別在於 /dev/urandom 通常不會 block：

The /dev/urandom device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.

而 /dev/random 不保證不會 block，有可能會因為 entropy 不夠而卡住：

/dev/random typically blocked if there was less entropy available than requested; more recently (see below, different OS's differ) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently.

然後順便講一下，因為這是 crypto 相關的設計修改，加上是 kernel level 的界面，安全性以及相容性都會是很在意的點，而 Hacker News 上的討論裡面很多是不太在意這些的，你會看到很多「很有趣」的想法在上面討論 XDDD

回到原來的文章，Jason A. Donenfeld (Linux kernel 裡 RNG maintainer 之一，不過近期比較知名的事情還是 WireGuard 的發明人) 最近不斷的在改善 Linux kernel 裡面這塊架構，這次打算直接拿 /dev/random 換掉 /dev/urandom：「Uniting the Linux random-number devices」。

不過換完後 Google 的 Guenter Roeck 就在抱怨在 QEMU 環境裡面炸掉了：

This patch (or a later version of it) made it into mainline and causes a large number of qemu boot test failures for various architectures (arm, m68k, microblaze, sparc32, xtensa are the ones I observed). Common denominator is that boot hangs at "Saving random seed:". A sample bisect log is attached. Reverting this patch fixes the problem.

他透過 git bisect 找到發生問題的 commit，另外從卡住的訊息也可以大概猜到在虛擬機下 entropy 不太夠。

另外從他們三個 (加上 Linus) 在 mailing list 上面討論的訊息可以看到不少交流：「Re: [PATCH v1] random: block in /dev/urandom」，包括嘗試「餵」entropy 進 /dev/urandom 的 code...

後續看起來還會有一些嘗試，但短期內看起來應該還是會先分開...

挑選開發者用的 Monospace 字型

Hacker News Daily 上看到的網站，直接使用對應的字型，讓使用者可以直接感覺：「Dev Fonts」。

目前上面有 33 種字型，大多都是免費的 (目前上面只有看到 Dank Mono 是收費的字型)。

在頁面上可以換 theme，以及選擇不同程式語言的 syntax highlighter，另外下方範例的程式碼也可以自己修改，這些都是讓使用者模擬實際的感受。

Google 與 Cloudflare 測試 Post-Quantum 演算法的成果

這幾年量子電腦的進展不斷有突破，雖然到對於攻擊現有的密碼學看起來還有一段時間，但總是得先開始研究對量子電腦有抵抗性的演算法...

其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品，兩個團隊合作測試的結果在學界與業界都還蠻重視的：「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。

Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel，有控制組與兩個新的演算法：

Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)

這兩個演算法有優點也有缺點。一個是 key 比較小，但運算起來比較慢 (SIKE，CECPQ2b)；另外一個是 key 比較大，但是運算比較快 (HRSS，CECPQ2)：

For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.

We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.

感覺還是會繼續嘗試，因為這兩個演算法的缺點都還是有點致命...

uBlock Origin 的開發版 (Dev) 被 Chrome Web Store 拒絕的事件...

uBlock Origin 是一個在瀏覽器上擋廣告的軟體，以前在推廣的時候都只提到可以過濾掉網站上的廣告，大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD)，但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」，大家接受度意外的爆高，不過這有點扯遠了，回到原來的主題上...

先介紹一下 uBlock Origin 的開發模式，除了一般的 stable 版本外 (「uBlock Origin」這組)，另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組)，這樣讓使用者比較容易安裝與測試，這個方式也可以在 Tampermonkey 上看到。

這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1 版上傳到 CWS 上後收到被拒絕上架的通知：「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。

拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」，也就是不能把目的不同的東西強迫使用者綁在一起使用：

Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose

後續的 1.22.5rc2 也被拒絕，然後他回信詢問了 CWS 官方，得到的仍然是罐頭回應，然後他就決定丟著 (而這個作法還蠻聰明的)，接著這件事情就被丟著變成 PR 事件上了一些媒體，然後昨天就突然解了...

Google 最近的動作愈來愈多了，一方面在嘗試避免觸動反托拉斯法的情況，儘可能打壓這些擋廣告的套件...

將本機開發網站展示給外部看的工具 inlets

要講 inlets 前要先講 ngrok 這個服務。這個服務可以在開發機上主動建立連線到外部伺服器，接著透過這個連線與本機的 web server 溝通，讓外部的客戶可以很方便的進行測試 (通常會開個 Zoom 之類的工具邊討論邊修改)，算是 reverse proxy as a service 的服務。

類似機制的服務還有 Cloudflare 的 Argo Tunnel，不過產品定位不太一樣。

而 inlets 就是 open source 版本的 ngrok，你只要在外部租一台主機就可以用了。左邊是自己的開發機 (像是 Macbook)，右邊則是外部的主機 (租用 VPS)：

不過這個跟開發模式也有關...

幫你在本機產生 localhost 的 SSL Certificate

mkcert 這個工具可以產生出讓系統 (包括瀏覽器) 信任的 https://localhost/：「mkcert: valid HTTPS certificates for localhost」。

先建立 CA 的 root key 與 root certificate，然後把 root certificate 塞到系統與各軟體的信任清單內，再產生 localhost 的 key 與 certificate 出來給前面的 CA root key 簽名。把這些事情包裝起來就是 mkcert 了。

拿來開發軟體時比較方便一點，HSTS 的程式碼就可以全環境共用了...

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話，利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援，而且產生速度很慢，一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試，像是在多種測試都是 Discrete uniform distribution，不需要防止有惡意人，可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面，作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed)，而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用：

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子，建議有需要接觸的人看過一次，或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法，像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator)，這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得：

  • 在大多數的程式語言內都有對應的 library 可以用，另外在比較近代的瀏覽器內 (如果問 IE 的話，是 11+)，可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出，在 Unix-like 的環境下可以透過 /dev/urandom 取得，在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD

Google 打算更廣泛的預設使用 HSTS

Google 宣佈了更廣泛開啟 HSTS 的計畫：「Broadening HSTS to secure more of the Web」。

然後先提到 .foo 與 .dev 的「Google Chrome 將 .dev 設為 HSTS Preload 名單」這件事情：

In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

接下來希望拋磚可以引玉：

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Google Chrome 將 .dev 設為 HSTS Preload 名單

其實是兩件事情... 第一件是 Google Chrome 把 .dev 結尾的網域設為 HSTS Preload 名單：「Chrome to force .dev domains to HTTPS via preloaded HSTS」。

第二件事情是隨著第一件來的，HSTS Preload 必須由 domain 擁有人提出啊... 所以 .dev 是合法的 TLD (gTLD)？

文章作者給了答案，是的，而且就是 Google 擁有的：

Wait, there's a legit .dev gTLD?
Yes, unfortunately.

(翻白眼)

這對開發者來說有種無奈感...

不過你可以用這招避開：「在 Google Chrome 連上因 HSTS 而無法連線的網站」，也就是輸入 badidea。

另外測試了一下，應該是所有的 A record 都會指到 127.0.53.53，如果有人懶得設定的話也可以用這個位置啦...