PuTTY 使用 ecdsa-sha2-nistp521 的漏洞

看到「PuTTY vulnerability vuln-p521-bias (greenend.org.uk)」這個消息,官網的說明在「PuTTY vulnerability vuln-p521-bias」這邊。

DSA 類的簽名演算法有個得很小心的地方,是 nonce 選擇不當會造成 key recovery,這在原文有提到:

All DSA signature schemes require a random value to be invented during signing, known as the 'nonce' (cryptography jargon for a value used only once), or sometimes by the letter k. It's well known that if an attacker can guess the value of k you used, or find any two signatures you generated with the same k, then they can immediately recover your private key.

維基百科的業面上也有提到這點:

With DSA, the entropy, secrecy, and uniqueness of the random signature value {\displaystyle k} are critical. It is so critical that violating any one of those three requirements can reveal the entire private key to an attacker. Using the same value twice (even while keeping {\displaystyle k} secret), using a predictable value, or leaking even a few bits of {\displaystyle k} in each of several signatures, is enough to reveal the private key {\displaystyle x}.

這次爆炸的起因是 PuTTY 用了 SHA-512 產生 nonce,這邊只會有 512 bits 的輸出,而這對 P-521 需要 521 bits 是不夠的 (於是前 9 個 bit 會是 0):

PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.

In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.

而更糟的是,這不僅僅是將降了 29 的安全性,而是因為 nonce 有 bias,這在 DSA 上已經足以從 60 次的簽出的 signature 中還原出 private key (也就是文章裡提到的 key recovery attack):

This bias is sufficient to allow a key recovery attack. It's less immediate than if an attacker knows all of k, but it turns out that if k has a biased distribution in this way, it's possible to aggregate information from multiple signatures and recover the private key eventually. Apparently the number of signatures required is around 60.

新版會改用 RFC 6979 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)) 實作:

To fix this vulnerability, we've completely abandoned PuTTY's old system for generating k, and switched to the RFC 6979 technique, for all DSA and ECDSA key types. (EdDSA keys such as Ed25519 already used a different system, which has not changed.) However, this doesn't affect the fact that information about existing P521 private keys has already been leaked whenever a signature was generated using the old k generator.

所以這次的 fix 得更新 PuTTY 版本,然後重新產生 private key (會假設已經 leak 了),然後看看系統有什麼要處理的...

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章,原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議,像是第一個建議是把 UUID 裡面的 - 拿掉,這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID,不會是念出來?)。

第二個建議是加上 prefix,這點不一定侷限在 UUID,只要是 token 上面都很適合。這個在不少系統上應該都有看過,像是 GitHub 的 token,或是 AWS 的 token 都算是這類。

文章裡面沒有提到,但這個建議也可以幫助你在 CI 上設定 regex,擋下把 secret token 寫進去的行為。

第三個提到用 base58,一方面是減少長度,另外一方面是想要避免 1IiLl0Oo 的問題,這點我覺得還好... 既然都是 copy & paste 了,我覺得拿 base62 (i.e. 大小寫加上數字) 不錯,這避免特殊字元無法選擇到,也就是文章裡面第一個建議。

第四個建議是建議重新思考 range,因為 UUID 的 128-bit range 很大,但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID,在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西,我就... 跳過了。

Windows 98 安裝的三階段

看到「Why does part of the Windows 98 Setup program look older than the rest? (2020) (retrocomputing.stackexchange.com)」這個,原文是 2020 的討論:「Why does part of the Windows 98 Setup program look older than the rest?」。

問題是 Windows 98 的安裝過程中段可以看出來有 Windows 3.1 介面的感覺,像這樣:

而到了後段又是 Windows 98 的感覺,作者覺得 UI 介面風格不一致的問題...

回答的人則是解釋得很清楚,第一階段是 DOS 階段,會把 Windows 3.1 環境疊出來:

The first, which can run from the setup floppies and/or CD-ROM, uses a DOS program (DOSSETUP.BIN) to set up disk partitions, run various checks etc.:

This phases finishes by copying a minimal version of Windows 3.1 to the target installation drive, in a temporary directory (normally WININST0.400), containing DOSX.EXE, USER.EXE, GDI.EXE, KRNL386.EXE, LZEXPAND.DLL etc. (see MINI.CAB).

第二階段則是 Windows 3.1 環境,把 Windows 98 大多數的東西都複製到硬碟上:

The second uses this minimal Windows 3.1 to run a Windows 3 program, W98SETUP.BIN (specified as the “shell” in SYSTEM.INI):

This starts by copying more files to support all the information-gathering during setup, and various other niceties including the 3D look shown in your screenshot (the contents of the PRECOPY CABs); it ends by copying most of Windows 98, setting the system up so that it will boot Windows 98 from the target drive, and rebooting.

第三階段則是 Windows 98 環境,執行後續的設定程式:

The third runs after the first boot into Windows 98, from Windows 98:

而且也提到了當年可以升級作業系統的情況 (雖然我自己偏好重裝):

It is also possible to initiate the setup process from any of the above environments, which is how Windows 98 handles upgrades (from MS-DOS, or Windows 3, or Windows 95).

是個解釋遺跡的現場 XDDD

把 terminal 軟體從 xfce4-terminal 換成 wezterm

我自從換到 Xubuntu 後一直都是用 xfce4-terminal,直到三月中的時候換成 wezterm 了,記得當時是在 Fediverse 上看到 gugod 說他用這套,測了一下覺得比 xfce4-terminal 好用,可以微調不少 xfce4-terminal 做不到的東西,就換過去了。

前陣子看到「Just How Much Faster Are the GNOME 46 Terminals?」這篇 (via),在 Hacker News 的討論裡面有提到另外一篇文章有測試 terminal latency 的問題:「Terminal Latency」,看了一下 wezterm 的速度不算快,不過 terminal 的速度目前不是我的痛點,所以還好:

(話說 xterm 居然是最快的...)

翻了一下之前在 2021 的時候有提到過 wezterm,不過當時是在講 vttest:「用 vttest 測試 terminal 程式實做的相容性」。

wezterm 是透過一個 Lua 檔案 (~/.wezterm.lua) 在管理設定的,而且預設支援 hot reload,所以不用太擔心會需要一直調整後重啟。

我的設定檔在 config repository 裡面有,不過我是建議自己花些時間調整,如果你是 terminal-heavy user 的話...

Fabrice Bellard 的新作品 TSAC codec

昨天在 Hacker News 上看到「TSAC: Low Bitrate Audio Compression (bellard.org)」這則 Fabrice Bellard 的新作品:「TSAC: Very Low Bitrate Audio Compression」。

Fabrice Bellard 這兩年玩很多 ML 相關的東西,像是 2021 的「LibNC: C Library for Tensor Manipulation」,以及 2023 的「ts_zip: Text Compression using Large Language Models」,這次則是用上了 transformer

tsac is based on a modified version of the Descript Audio Codec extended for stereo and a Transformer model to further increase the compression ratio. Both models are quantized to 8 bits per parameter.

翻了一下 Descript Audio Codec,已經算是很厲害的了,在 44.1KHz mono 的情況下可以做到 8kbps (~1KB/sec):

With Descript Audio Codec, you can compress 44.1 KHz audio into discrete codes at a low 8 kbps bitrate.

TSAC 則是將 mono 的版本做到 5.5kbps,另外 7.5kbps 就能傳雙聲道,也還是低於原來的 8kbps:

TSAC is an audio compression utility reaching very low bitrates such as 5.5 kb/s for mono or 7.5 kb/s for stereo at 44.1 kHz with a good perceptual quality. Hence TSAC compresses a 3.5 minute stereo song to a file of 192 KiB.

聽了一下算蠻厲害的,直接拿音樂來壓還是有不錯的效果?

從技術上的情境可以知道兩端都需要有足夠的算力 (得跑 ML algorithm),然後在頻寬很不足的情況下通訊?商用的情境好像偏少一點,現在連沙漠與深山中都有衛星可以用,也許還是有些情境下用的到,像是 LoRa 的速度就差不多在這個區間。

倒是軍事上面需要考慮不少極端情況,用的機會可能比較高?

Automattic 買下 Beeper

沒想到後續消息居然會是這個,在 Hacker News 上看到 Automattic 買下 Beeper 的消息:「Beeper acquired by Automattic (WordPress) (beeper.com)」,原文在「Beeper is joining Automattic」這邊。

先前因為弄出與 iMessage 相通的工具而知名,當時還追過這個新聞:

看起來之前就有投資的關係了:

Matt, Automattic’s CEO, and I have known each other for years. He was an early user, supporter and investor in Beeper.

不確定買下來能做什麼,新聞稿上講得是很冠冕堂皇... 但對 Beeper 的創辦人這邊大概就是順利脫手?當時 Apple 的態度讓 iMessage 相容性這條路走到 dead end;對 Automattic 這邊大概就是希望這群人做 IM project?

不過當時已經買了 Texts.com (參考當時的新聞「WordPress.com owner buys all-in-one messaging app Texts.com for $50M」),原來這組人是有什麼狀況嗎...?

Google 推出 Jpegli:JPEG 的 encoder 以及 decoder

Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」,原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小:

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較,大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了,應該是跟 cjpeg 比,如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯,這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品:

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名,比較熟的是 Zopfli 以及 Brotli

IEEE 也宣佈禁用 Lenna 圖了

Lenna (Lena) 是個經典的標準測試圖片,一方面是因為有很多細節可以觀察 image-related algorithm 的情況,另外一方面也是因為這張圖是取自 1972 年的 Playboy 雜誌:

Lenna (or Lena) is a standard test image used in the field of digital image processing starting in 1973, but it is no longer considered appropriate by some authors.

To explain why the image became a standard in the field, David C. Munson, editor-in-chief of IEEE Transactions on Image Processing, stated that it was a good test image because of its detail, flat regions, shading, and texture. He also noted that "the Lena image is a picture of an attractive woman. It is not surprising that the (mostly male) image processing research community gravitated toward an image that they found attractive."

也因為後者的原因,後來也有愈來愈多其他的圖片可以達到類似的效果 (甚至更好),就有替代的聲音出現了。

另外一方面,Lena 本人在 2019 年也提到希望淡出的想法:「How a Nude “Playboy” Photo Became a Fixture in the Tech World」。

But I retired from modeling a long time ago. It’s time I retired from tech, too.

而最新的消息就是 2024/04/01 開始,IEEE 不再接受使用 Lenna 圖的投稿:「Institute bans use of Playboy test image in engineering journals」。

之後大概只會在歷史回顧的時候會引用提到了...

利用信件裡面的 CSS,讓文字只在轉寄後才出現

在「Kobold letters: HTML emails are a risk (lutrasecurity.com)」這邊看到的 security advisory (算... 是吧?),原文在「Kobold Letters」這邊,如同標題寫的,方法其實意外的簡單...

Thunderbird 是透過 .moz-text-html>div> 指定就可以達到效果:

Outlook on the web (i.e. 雲端版本) 則是有在 id 上面增加隨機的 prefix 避免,但可以用 body>div> 避開,另外有些眉眉角角的地方會稍微複雜一點,但還是可行的:

Gmail 則是直接用個簡單的 css selector 掛上 display: none; 就 OK 了:在 sender 端 (轉寄者) 看不到,在 receiver 端則可以 (效果更好?):

比較慘的是目前大家都沒有想到比較好的解法,就算這次提到的方法被補上了,應該還是很容易被繞過去:

Unfortunately, for the foreseeable future, it is sadly not realistic to expect email clients to implement robust mitigation. This means that it is up to the users to be aware of the dangers of HTML emails and to take the necessary precautions.

另外文章裡面提到了 Can I email 這個網站,看起來如果要自己處理 email 內容的話是個不錯的資源...

把 MIT license 當歌詞寫歌...?

在「AI-generated sad girl with piano performs the text of the MIT License (twitter.com/goodside)」這邊看到的推,把 MIT License 的條文當歌詞丟進去寫歌 (應該是最近很紅的 Suno.ai?):

WTF...