64 位元整數中僅 17% 能被表示為兩個 32 位元整數的乘積
lemire.me · 2026-05-22
Daniel Lemire 在部落格分析了一個看似簡單的整數算術問題：所有 64 位元無號整數中，有多少可以寫成兩個 32 位元無號整數的乘積？答案令人意外——僅有約 17%，精確數字為 3,215,709,724,700,470,902 個（約 3.22 × 10¹⁸），在 2⁶⁴ ≈ 1.84 × 10¹⁹ 的全域空間中佔比 17.46%。
數學基礎
此結果建立在 Erdős 的工作之上：「所有 2n 位元值中，能由兩個 n 位元整數相乘生成的比例，在 n 趨近無窮時趨近於零。」換言之，乘積空間相對於輸出範圍的稀疏程度隨位元數增加而加劇。Webster 等人開發了可擴展的計算方法，能夠對實際位元寬度精確計算這個比例：給定目標乘積 P，分解其質因數，系統性枚舉所有小於 2³² 的因子，並驗證對應的互補因子也在 32 位元範圍內。
對哈希函數設計的影響
這個結論的實際意義源於哈希函數設計。一個簡單的 64 位元哈希，若採用「將輸入拆為高 32 位元與低 32 位元後相乘」的方式，理論上有 83% 的輸出空間永遠無法被生成——輸出分佈嚴重不均。對需要均勻雜湊分佈的應用場景（如雜湊表、一致性雜湊、布隆過濾器），這種設計會引入系統性偏差。
這也解釋了為何高品質的哈希函數（MurmurHash3、xxHash、wyhash）都刻意迴避簡單的 32×32→64 乘法，改用精心設計的混合步驟（mixing steps）來確保雪崩效應（avalanche effect）覆蓋整個輸出空間。
直覺化理解
從另一個角度想：隨機選取一個 64 位元整數，它有 83% 的機率無法被任何兩個 32 位元整數相乘得到。乘法運算在 64 位元空間中製造的「洞」遠比多數工程師直覺預期的要多，且這個現象隨著位元寬度增加而指數惡化。
原始來源：Daniel Lemire's Blog
Noroboto：字型 cmap 偽造攻擊與 Rust OCR 驗證防禦
tritium.legal · 2026-05-22
Tritium 法律科技公司揭露 Noroboto 字型偽裝技術：透過篡改 TrueType 字型的 cmap（character map）表，讓文件在視覺上顯示正常文字，但底層 Unicode 資料完全不同。這對 AI 文件分析系統構成重大威脅——模型可能讀取到與人眼所見截然不同的文字內容，尤其在具有法律效力的合約文件中風險最高。
cmap 偽造機制
TrueType cmap 表建立 Unicode 碼位（code point）到字形（glyph）輪廓的對應關係。攻擊分兩種層次：
- 完整混淆（Full Obfuscation）：將字形對應至 Unicode 私用區域（Private Use Area, PUA）的碼位，大多數應用程式顯示為豆腐塊（tofu）。Noroboto 字型提供吻合的字形輪廓，使視覺渲染正常，但底層資料是無意義的 PUA 碼位。
- 替換攻擊（Replacement Attack）：更精密的變體，將字形 A 的輪廓對應至字形 B 的 Unicode 碼位，使視覺顯示「Maryland」但底層編碼為「Delaware」。需要為每個替換字嵌入對應字型。
對法律文件的威脅尤為嚴峻：字型 metrics 決定頁面排版與分頁，而頁碼在法律文件中具有明確的引用意義。攻擊者可隱藏「後繼者與受讓人」條款，或篡改管轄法律條款。
AI 系統的脆弱性
邊界模型（frontier LLM）在處理具有推理能力的視覺輸入時，可透過 OCR 方式識別出完整混淆攻擊，但對替換攻擊仍高度脆弱。「Agent 傾向於相信表面的 Unicode 編碼而非渲染驗證」——除非明確要求對每個字形做 OCR 驗證，否則替換攻擊可透過文字層欺騙模型。
Rust 的信任但驗證防禦
Tritium 的 Rust 實作採取「保留原始字型，但透過 OCR 驗證字形誠實性」策略：
// 以 ASCII 字元生成字型圖集（font atlas）
// 計算 OCR 輸出與預期文字的 Levenshtein 準確率
accuracy = 1.0 - (levenshtein_distance / expected_length)
// 準確率 < 1.0 → 觸發可疑字型告警使用 macOS/Windows 原生 OCR 或 Linux 上的模型推論，在字型圖集上測試 ASCII 字母數字。完美分數（1.0）代表字型誠實；任何偏差即為潛在偽造信號。此方法可識別替換攻擊，但無法在所有情況下確定性保證，因為攻擊者可接受較低的 OCR 分數作為代價。