Elliptic-Curves
RFC6979:參考實現中的錯誤?
如果我正確理解RFC 6979 ,則 ref 實現第 3.2 節中存在錯誤。
在步驟 H2 中,RFC 規範說
2. While tlen < qlen, do the following: V = HMAC_K(V) T = T || V
但是在RFC附錄的Java實現中,我們發現了與rolen的比較
這不會提供相同的結果。
例如,如果與質數場等於 的 Stark 曲線一起使用
0x0800000000000011000000000000000000000000000000000000000000000001
,則qlen為252,rolen為 256因此,循環使用rolen發生兩次,但使用**qlen僅發生一次。它不會改變第一個 k 值,但隨後的 k 會改變。
現在已經從第三個軟體使用了 RFC 程式碼。
有沒有想過?
RFC 以比特的形式指定事物。每次呼叫 HMAC 都會輸出
hlen
位。tlen
是到目前為止獲得的位數;當至少qlen
獲得比特時,此步驟完成。範常式式碼是用 Java 編寫的,其中資訊的基本單元是八位字節(通常術語中的“字節”)。支持的散列函式總是輸出給定數量的字節,並且沒有小數字節。換句話說,在該程式碼中,
hlen
始終是 8 的倍數。這意味著它tlen
也是 8 的倍數。該
rolen
值是以q
八位字節為單位的長度;也就是說,它等於qlen/8
,四捨五入。這在程式碼中是可以的,因為hlen
它是 8 的倍數。例如,對於qlen
252 的曲線,生成需要來自 HMAC 的 252 位輸出;但由於hlen
是 8 的倍數,如果沒有至少 256 位的輸出,就無法獲得 252 位的輸出。因此,程式碼可以跟踪計數八位字節(因此,rolen
)而不是位的事物。使用 HMAC/SHA-256,每次 HMAC 呼叫可獲得 32 個字節的輸出;並且rolen
是 32。因此,一次呼叫就足以獲取rolen
字節,並且不會有第二次呼叫。