為什麼 Ed25519 標量乘法允許值大於子組順序？

GeScalarMultBase函式是這樣記錄的。從它的記錄方式中，我們看到它需要一個小端值，並且有一個限制它接受的範圍的前提條件。

// GeScalarMultBase computes h = a*B, where
//   a = a[0]+256*a[1]+...+256^31 a[31]
//   B is the Ed25519 base point (x,4/5) with x positive.
//
// Preconditions:
//   a[31] <= 127
func GeScalarMultBase(h *ExtendedGroupElement, a *[32]byte) {

我對橢圓曲線的理解讓我認為標量點乘法的可接受值範圍應該在

$$ 0, subgroup_order $$. 雖然它可以接受更大的值，因為 $ (n+x)G = xG \pmod n $ 這在計算上會很浪費，所以我希望該函式將其限制為子組順序，或者在使用它之前始終對其進行修改。 在Ed25519 中，順序常數的定義如下：

field_order 2**255 - 19
subgroup_order 2**252 + 27742317777372353535851937790883648493

將這些與該方法文件所說的進行比較：

# hex in little-endian
field_order: 0xdefffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7
subgroup_order: 0xde3d5fc5a13621856dc97f2aed9fed4100000000000000000000000000000001
GeScalarMulBase states: a[31] <= 127 (0xf7)
field_order[31]: 0xf7 (127)
subgroup_order[31]: 0x01 (16)

由於我們使用 little-endian，字節 31 是最重要的字節，我們從文件中看到該函式強制它小於 127，這映射到欄位順序。

這似乎表明它接受範圍內的值

$$ 0, curve_order $$而不是我的期望$$ 0, subgroup_order $$. 我對正在發生的事情的理解是否準確？如果是這樣，是否有特殊原因允許值大於子組順序？

我對橢圓曲線的理解讓我認為標量點乘法的可接受值範圍應該在

$$ 0, group_order $$.

實際上，情況並非如此 - 點乘法 $ xG $ 對於所有的整數值是明確定義的 $ x $ .

雖然它可以接受更大的值，因為 $ (n+x)G=xG $ ，這在計算上會很浪費，所以我希望該函式將其限制為組順序，或者在使用它之前始終對其進行修改。

好吧，在密碼學上這將是有效的，但是這將允許進一步的“優化”，而丹希望避免允許善意的實現者。

如果有人要實現點乘法 $ xG $ 以直接的方式（其中 $ x $ 是一個介於 $ 0 $ 和 $ n $ )，他們可能會注意到，有時， $ x $ 少於 252 位 - 在這種情況下，他們可能會跳過點乘邏輯的那些迭代（因此會稍微加快速度）。這聽起來像是一個很好的優化，但是它引入了一個（小的）時間洩漏（因為所花費的時間取決於秘密數據），而 Dan真的想避免任何這樣的洩漏。

通過確保 $ x $ 是一個介於 $ 2^{254} $ 和 $ 2^{254}+n $ （因此是固定數量的比特），任何這樣的優化都遠不那麼直接（並且到目前為止，我們善意的實現者不太可能發生）

引用自：https://crypto.stackexchange.com/questions/71770