constant-time-analysis

constant-time-analysis 技能概覽

constant-time-analysis 是一個安全稽核技能，用來在加密程式碼的 timing side-channel 風險變成可被利用的漏洞之前，先把它找出來。它最適合工程師、審查者，以及 AI 代理人用來檢查：那些依賴 secret 的運算、分支、比較或執行期指令，會不會洩漏金鑰、token 或其他敏感值。

它真正要解決的不是「理解密碼學理論」，而是「找出這段程式在哪裡不再是 constant-time」。因此，constant-time-analysis 技能最適合用在實作審查、合併前的安全檢查，以及事件分流判斷：當有人想確認某個函式是否能抵抗 timing attack 時。

它和一般 prompt 的差異在於：它是以編譯後的輸出和語言專屬分析路徑為核心，而不只是掃描原始碼。這一點很重要，因為 constant-time 問題常常會出現在 assembly、bytecode 或 VM 指令層，即使原始碼看起來完全無害。

constant-time-analysis 在 Security Audit 的最佳適用情境

當你在審查以下程式碼時，最適合使用這個技能：

• 處理 secret、驗證或 cryptographic primitives
• 使用除法、取模、比較，或根據 secret-derived values 做分支
• 需要針對編譯後產物驗證，而不只是看原始碼意圖
• 目標語言是 C、C++、Go、Rust、Swift、Java、Kotlin、PHP、JavaScript、TypeScript、Python 或 Ruby

constant-time-analysis 能抓到什麼、抓不到什麼

constant-time-analysis 對 timing leak 型態很強，例如變動時間的除法、依賴 secret 的分支，以及不安全的比較。
但它對更廣泛的密碼學設計錯誤、通訊協定缺陷，或來自網路、快取、環境雜訊的洩漏，能力較弱——除非這些問題直接出現在被分析的程式路徑中。

為什麼使用者會安裝它

當你想要一套可重複的審查流程，而且能比人工快速瀏覽更早標出 timing 風險時，就該安裝這個技能。
如果你只是想針對單一片段得到一次性的判斷，普通 prompt 可能就夠了；但如果你需要一致的安全審查行為，這個技能會提供更清楚的結構。

如何使用 constant-time-analysis 技能

正確安裝並觸發 constant-time-analysis

先透過你的 skill manager 使用 constant-time-analysis 的安裝路徑，接著在包含目標語言與敏感函式或檔案的情境中執行它。好的觸發 prompt 會明確寫出密碼學目標、secret 輸入，以及語言／執行環境，讓技能選對分析路徑。

觸發範例：

• “Review src/sign.rs for constant-time risk. Secret input is the private key scalar; focus on division, branches, and comparisons.”
• “Run constant-time-analysis on this PHP password-checking function and tell me whether any opcode-level timing leak is likely.”

提供正確的輸入形狀

這個技能在你提供下列資訊時表現最好：

• 要檢查的檔案或函式
• 哪些值是 secret
• 哪些對攻擊者可觀察的行為很重要
• 若已知，目標語言與 runtime 版本

較好的輸入：

• “Audit verifyToken() in TypeScript. Token bytes are secret; compare against stored HMAC; check for Div, Mod, and early-exit comparisons.”
• “Analyze this Rust reduce() routine for secret-dependent division across x86_64 and arm64.”

先讀這些檔案

若你是為了安裝決策與實際工作流程，建議先從這些檔案開始：

• SKILL.md：觸發條件、範圍與語言選擇
• README.md：支援的語言與輸出目標
• references/compiled.md：C/C++、Go、Rust
• references/javascript.md、references/python.md、references/php.md、references/ruby.md、references/swift.md、references/kotlin.md：各 VM 的特定規則

如果你只打算快速看一個 reference 檔，請選和你的 runtime 路徑一致的那個，而不是只看原始碼語言名稱。

用審查流程，不要只跑一次就結束

實際的 constant-time-analysis 使用流程通常是：

1. 找出碰到 secret 的函式
2. 套用對應的語言指南
3. 檢查任何除法、取模、比較、分支，或可疑的 helper 呼叫
4. 在重構或 compiler/runtime 變動後重新執行
5. 如果你想把結果納入機器化檢查，要求 CI 友善的輸出

這很重要，因為即使原始碼修掉了，編譯後仍可能生成不安全的指令，尤其是在編譯型語言裡。

constant-time-analysis 技能 FAQ

constant-time-analysis 只適用於密碼學嗎？

不是。它適用於任何「secret 的 timing 差異有意義」的程式碼，但通常會落在 crypto、auth、金鑰處理與 token 驗證這些場景。
如果程式只處理公開資料，這個技能大多沒必要。

我需要懂 assembly 或 bytecode 嗎？

一開始不需要。這個技能之所以有用，正是因為它會把你導向正確的 runtime 產物與語言專屬參考資料。你不必讀懂每一條指令，但你需要知道哪個函式或檔案是安全敏感的。

constant-time-analysis 比一般 prompt 更好嗎？

在你需要可重複的安全審查行為時，答案是肯定的。一般 prompt 也能指出明顯風險，但 constant-time-analysis 更適合 repository 工作，因為它的結構是圍繞語言選擇、編譯後輸出，以及具體的洩漏模式來設計的。

什麼情況不該用它？

不要拿它來看一般商業邏輯、UI 程式碼，或只是在做公開資料轉換的場景。
如果某個 library 已經保證 constant-time 行為，而你只是想確認高層 API 用法、沒有自訂的 secret-dependent 邏輯，也可以略過它。

如何改進 constant-time-analysis 技能

聚焦 secret 與攻擊者模型

最好的 constant-time-analysis 結果，來自於你明確指出「哪些東西必須保密」以及「攻擊者看得到什麼」。
請說清楚風險是遠端 timing、同機程序 timing，還是編譯後程式碼檢視。若沒有這些資訊，技能可能過度聚焦在無害分支上，或反而錯過真正的限制。

提供最小的高風險程式路徑

只給真正碰到 secret 資料的函式，不要整個 repository 都丟進去。
如果路徑裡有 helper，只在它們會影響分支、運算或比較時才一起提供。這樣可以減少雜訊，也更容易把結果落實。

要求語言專屬證據

要得到最佳結果，請要求技能檢查對應的 runtime 產物：

• C/C++、Go、Rust：assembly
• JavaScript、TypeScript、Python、Ruby、PHP：bytecode
• Kotlin：JVM 行為

這會提升 constant-time-analysis 的使用效果，因為 timing leak 往往是在 source level 之下才浮現。

每次修正後都重新執行

常見的失誤模式是：改了原始碼，就以為 leak 已經消失。
請在調整演算法、compiler flags、最佳化等級，或 runtime 版本後再次測試。對 constant-time-analysis for Security Audit 來說，第二輪往往才是真正確認安全狀態的時候。