Lamport OTS 是否通過使用 HMAC 得到改進？
Lamport OTS 的一個問題是攻擊者可以反复嘗試隨機輸入，並且隨機輸入的散列有可能匹配大量公鑰中的一個，從而在一定程度上降低了安全裕度。
但假設第 i 位的公鑰計算為
[ TRUNCATE-128(HMAC(S0,i||"0")) , TRUNC-128(HMAC-SHA256(S1,i||"1")) ]。發件人顯示
S0或S1。現在，驗證者不僅期望任何散列到給定值的字元串，還期望得到一個密鑰
Sx（要麼 要麼S0）S1，並期望TRUNC-128(HMAC-SHA256(Sx,i||bitvalue))評估該位值的公鑰部分。現在攻擊者不能簡單地生成隨機字元串並讓它們匹配潛在的多個公鑰。
這會提高安全邊際並允許將 128 位簽名用於精確的 128 位（經典）安全性嗎？
這會提高安全邊際並允許將 128 位簽名用於精確的 128 位（經典）安全性嗎？
是也不是 - 是的，它會稍微提高安全邊際，但不會提高到完整的“128 位經典安全級別”。
至於為什麼它不會將其提升到完整的 128 位級別，嗯，有兩個原因：
一方面，攻擊者可以猜測
S0併計算TRUNCATE-128(HMAC(S0,i||"0"))它是否恰好是公鑰中的值；這可能有兩個原因：
- 他的猜測
S0恰好是正確的；如果S0是 128 位，這很有可能發生 $ 2^{-128} $- 他的猜測
S0是錯誤的，但TRUNCATE-128(HMAC(S0,i||"0"))無論如何恰好是正確的值；如果我們將 HMAC 建模為一個隨機函式，那麼這很有可能發生 $ 2^{-128} $因此，這兩種情況發生的機率大約為 $ 2^{-127} $ ，給我們一個略低於 128 位的安全級別。
- 另一方面，讓我們假設對手有 $ M $ 公鑰、消息和簽名（每條消息都是 $ N $ 位）；他能做的是嘗試猜測
S0每個私鑰的第一位；如果他成功（對於任何具有1第一位的消息，因此S1被使用），那麼他可以為該公鑰生成該偽造。如果我們假設對手的目標是偽造其中一個公鑰（他不在乎哪個），那麼預期的工作量是 $ 2^{-128} / (N/2) $ （與 $ N/2 $ 因子是具有0第一位的近似消息）；對於大 $ N $ 這顯然是安全性的重大降低。現在，對第一個觀察的明顯防禦是增加和的大小
S0（S1這將導致簽名大小的增加）。而且，與第二個觀察相反，您需要以某種方式將一些每個公鑰的區分符（以及您的提案所做的“位位置”）加入到單向函式中。如果您查看目前標準的基於散列的簽名方法（LMS、XMSS、Sphincs+），他們會這樣做（使用各種技術來攪動事物 - 它們都不使用 HMAC）。
將 HMAC 與 Lamport OTS 一起使用的優勢在於它提供了針對長度擴展攻擊的保護。如果您想通過將種子 + 遞增索引輸入散列函式來從單個秘密種子安全地派生多個唯一私鑰，這一點很重要。
如果沒有 HMAC，密鑰生成算法的安全性可能會降低，因為攻擊者可能會通過查看上一條消息上使用的最後一個簽名和公鑰並使用長度擴展攻擊來導出下一個公鑰和在不知道秘密種子或任何私鑰的情況下在序列中籤名。
SHA256 不能防止長度擴展攻擊，但 HMAC-SHA256 可以。