Tag: number

從 e-mail 取得電話號碼

Hacker News 上看到 2019 年的文章：「From email to phone number, a new OSINT approach (2019) (martinvigo.com)」，原文在「From email to phone number, a new OSINT approach」。

用的原理是每一家在 recovery 時都會透漏電話號碼的不同部位，從截圖可以看到像是 PayPal 給的是區碼地一碼加上後三碼：

然後他整理出來：

Leaks first three and last two digits:
eBay

Leaks first and last four digits:
Paypal

Leaks first and last two digits:
Yahoo

Leaks last four digits:
Lastpass

Leaks last two digits:
Google
Facebook
Twitter
Hotmail
Steam

接著文章裡面介紹了其他的方法再縮小可能性，然後再反過來利用電話號碼查 e-mail，像是 Amazon：

後面則是示範了這整套過程可以自動化。

可以確認電話號碼後可以做的事情就很多了，文章裡面提到的也只是一小塊...

Amazon EBS 十五週年，以及一些數據

AWS 的 SVP James Hamilton 寫了一篇「Amazon Elastic Block Store at 15 Years」在講 Amazon EBS 的十五週年，裡面提到了一些數字。

目前的每天的 IOPS 是 100 trillion，如果攤平的話大約是 11.57 billion IOPS/sec，如果很單純以目前高階 NVMe 卡大約是 1M IOPS/sec 這個數量級來算的話，在沒有任何 redundancy 架構，需要的量大約是萬張？以 AWS 的量感覺好像是個合理的數字... 考慮到 IOPS 主力應該是 SSD 或 NVMe 類的應用，加上 redundancy 以及保留 burst 空間的架構，最少有個十萬張... 應該不算有問題。

I asked the EBS team to quantify customer usage in 2023, the 15th year of EBS. Focusing first on daily usage, EBS delivers more than 100 trillion input/output operations per day.

另外一個是傳輸量，每天有 13EB，攤平大約是 150.46TB/sec，如果用上面提到的十萬顆來攤的話大約是需要 1.5GB/sec 的速度，拿數量級來算應該是差不多。

Perhaps even more staggering is the fact that EBS transfers more than 13 exabytes of data for customers every day.

另外一個是百萬客戶 (也許是帳號) 每天會開出三億個 EBS storage，我猜這跟機器的起起落落有關，現在 EC2 開機主要都是要掛 EBS 的 boot disk 了：

Continuing to focus on daily usage, millions of customers use EBS daily, and these millions of customers create more than 390 million EBS storage volumes each day.

的確如同 James Hamilton 說的，EBS 現在已經變成一個蠻重要的基礎建設了，很多 AWS 上的服務都是架在他上面，像是 RDS 利用了 EBS 的 block replication 組出了 readonly repica，而非走傳統的 replication 路子。

自己小修一下 fcitx5-mcbopomofo 的選詞數量

之前有提過「Linux 上 fcitx5 的小麥輸入法」，在我自己桌面都換成 Ubuntu 22.04 後都能裝了，就用了一陣子。

但選字的數量一直覺得怪怪的，本來的數量是九個，像是這樣：

看了一下 Windows 上的新酷音，介面上因為設計成 3x3 的關係，所以看起來就不會不舒服：

所以就在想，如果是一行的為什麼不是十個？翻了翻程式碼，看起來在 src/McBopomofo.cpp 這邊：

  if (keysConfig == SelectionKeys::Key_asdfghjkl) {
    selectionKeys_.emplace_back(FcitxKey_a);
    selectionKeys_.emplace_back(FcitxKey_s);
    selectionKeys_.emplace_back(FcitxKey_d);
    selectionKeys_.emplace_back(FcitxKey_f);
    selectionKeys_.emplace_back(FcitxKey_g);
    selectionKeys_.emplace_back(FcitxKey_h);
    selectionKeys_.emplace_back(FcitxKey_j);
    selectionKeys_.emplace_back(FcitxKey_k);
    selectionKeys_.emplace_back(FcitxKey_l);
  } else if (keysConfig == SelectionKeys::Key_asdfzxcvb) {
    selectionKeys_.emplace_back(FcitxKey_a);
    selectionKeys_.emplace_back(FcitxKey_s);
    selectionKeys_.emplace_back(FcitxKey_d);
    selectionKeys_.emplace_back(FcitxKey_f);
    selectionKeys_.emplace_back(FcitxKey_z);
    selectionKeys_.emplace_back(FcitxKey_x);
    selectionKeys_.emplace_back(FcitxKey_c);
    selectionKeys_.emplace_back(FcitxKey_v);
    selectionKeys_.emplace_back(FcitxKey_b);
  } else {
    selectionKeys_.emplace_back(FcitxKey_1);
    selectionKeys_.emplace_back(FcitxKey_2);
    selectionKeys_.emplace_back(FcitxKey_3);
    selectionKeys_.emplace_back(FcitxKey_4);
    selectionKeys_.emplace_back(FcitxKey_5);
    selectionKeys_.emplace_back(FcitxKey_6);
    selectionKeys_.emplace_back(FcitxKey_7);
    selectionKeys_.emplace_back(FcitxKey_8);
    selectionKeys_.emplace_back(FcitxKey_9);
  }

看起來是為了跟 asdfghjkl 九個鍵對齊設計的，但這樣覺得不舒服... 所以在 selectionKeys_.emplace_back(FcitxKey_9); 後面加上 selectionKeys_.emplace_back(FcitxKey_0);，再重新編 + 裝 + 重啟後再輸入就變成十個了：

這樣自己用是沒問題，但暫時想不到怎麼找出一個好方法併回去... 也許多一組 SelectionKeys::Key_1234567890？

fp32、fp16 與 bf16

在 nanoGPT 這個專案下面看到 bf16 這個浮點格式：(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16，是由 Google 的團隊所提出來的想法，主打是與 fp32 相同的表示範圍，但是犧牲精度，這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement)：

然後同一頁也看到各家自己推出不同的格式，這邊看起來比較像是市場競爭的關係...

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...

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

Linux Kernel 裡的 RNG 從 SHA-1 換成 BLAKE2s

從 Hacker News Daily 上看到的消息，Linux Kernel 裡的 RNG，裡面用到的 SHA-1 演算法換成 BLAKE2s 了：

SHA-1 已知的問題是個隱患，不過換成 BLAKE2s 應該是 maintainer 的偏好，Jason Donenfeld 在 WireGuard 裡面也是用 BLAKE2s...

把 YouTube 的 Dislike 數字弄回來

最近 YouTube 也在搞事，把 Dislike 的數字拔掉了，後來在 Greasy Fork 上面找了一下，看到有兩套方法可以把數字補回來。

第一套是「Return YouTube Dislike」這個方法，從程式碼裡面可以看到是透過 API 拉出來的：

function setState() {
  cLog('Fetching votes...');
 
  doXHR({
    method: "GET",
    responseType: "json",
    url:
      "https://return-youtube-dislike-api.azurewebsites.net/votes?videoId=" +
      getVideoId(),
    onload: function (xhr) {
      if (xhr != undefined) {
        const { dislikes, likes } = xhr.response;
        cLog(`Received count: ${dislikes}`);
        setDislikes(numberFormat(dislikes));
        createRateBar(likes, dislikes);
      }
    },
  });
}

這個 API 後面應該是接 Videos: getRating 拉資料出來，但畢竟不是直接打 YouTube API (比較麻煩，需要每個使用者自己申請 API token)，這樣就有隱私的疑慮了...

另外一套是「Show Youtube Dislike Count」，看了裡面程式碼發現他是用 averageRating 反推回來：

if (likeCount >= 0) {
    const r = data.playerResponse.videoDetails.averageRating;
    const dislikeCount = Math.round(likeCount * (5 - r) / (r - 1));

    ShowDislikes(likeCount, dislikeCount);
}

不過作者有點偷懶，這邊在等待頁面生成單純用 100ms 等頁面出現，有時候還是會有 race condition (就是後面還是讀不到 XDDD)，如果懶的大修的話可以改成 1000ms 混過去，降低一些機率：

while (!isLoaded) {
    await Sleep(100);
}

另外數字很大的時候會稍微不準，但也算夠用了，先暫時用這套來頂著了...

Kaspersky Password Manager 的漏洞

在 Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇，講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞，另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。

標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。

這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG，而且也沒有正確 seed，所以極為容易被猜出密碼本身。

KPM 的 Web 版使用了 Math.random()，在各家瀏覽器主要是用 xorshift128+ 實做 Math.random()，作者沒有針對這塊再花時間研究，但很明顯的 Math.random() 不是個 CSPRNG：

The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

而桌機版則是用了 MT19937，理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output)，但這代表你要知道其他網站的密碼，這點其實有點困難。

但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關，超級容易被預測：

So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

於是可以直接暴力解出所有的可能性：

The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.

Hacker News 上有不少陰謀論的討論，像是：

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

另外 Kaspersky 跟俄羅斯軍方的關係也是很知名，這些東西大概要到十來年後才會知道...

Facebook 5.33 億筆個資外洩，以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情：「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的，不過這份資料看起來也不是完整資料，舉個例子來說，台灣只有 73 萬筆左右，而且也少了很多地區，像是泰國就不在列表內...

另外一個比較特別的是，Mark Zuckerberg 的電話也在這次外洩資料裡面：「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」，應該會換號碼了。

這包資料看起來會這陣子會很熱門...

YAML 的問題 (挪威問題)

Hacker News 首頁上看到的，YAML 寫多的人都遇過類似的問題：「The Norway Problem - why StrictYAML refuses to do implicit typing and so should you」，對應的討論「The Norway Problem (hitchdev.com)」也可以看一下。

第一個「經典」是字串不需要包起來就很容易出事，這邊提到的例子是因為保留字而中槍，挪威的簡碼 NO 變成 False 了：

countries:
- GB
- IE
- FR
- DE
- NO
>>> from pyyaml import load
>>> load(the_configuration)
{'countries': ['GB', 'IE', 'FR', 'DE', False]}

同樣的是字串問題，「看起來」是數字的就會變成數字：

python: 3.5.3
postgres: 9.3

然後還是字串，人名遇到保留字：

first name: Christopher
surname: Null

這種問題都是碰過一次學一次...

作者另外提到的 StrictYAML 改變了 YAML 規格，我會看看就好，能用 JSON 也許還是會偏好先用 JSON，不是完全解決，但踩雷的機率會少很多。