Curve25519 上的密鑰表示

https://datatracker.ietf.org/doc/html/draft-josefsson-tls-curve25519-06#appendix-A.2提供以下作為密鑰/公鑰組合：

        S_a = 0x6A2CB91DA5FB77B12A99C0EB872F4CDF
                4566B25172C1163C7DA518730A6D0770

        P_a = 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
              0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A

https://www.rfc-editor.org/rfc/rfc7748#section-6.1給出了另一個密鑰/公鑰組合：

Alice's private key, a:
 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
Alice's public key, X25519(a, 9):
 8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a

請注意，兩者的公鑰是相同的，但私鑰卻不同。

sodium_crypto_box _publickey_from_secretkey似乎同意 RFC 但不同意 IETF 草案：

https://3v4l.org/i61aE

我的問題是…… RFC 在做什麼而草案不是？

我問是因為我有一個實現，它可以從 IETF 草案中的密鑰中給我正確的公鑰，我想這樣做，以便我可以使用相同的實現從密鑰中的密鑰中獲取公鑰IETF RFC。但是，更重要的是，我只是好奇。

謝謝！

我很確定這是一個字節順序問題。具體來說，S_a從Josefsson 草案中獲取值並反轉其中的字節順序（即成對的十六進制數字）給出：

70076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c6a

這與RFC 7748 § 6.1中給出的值幾乎相同。事實上，對這些值進行異或運算表明它們只有四位不同：a

 70076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c6a
⊕ 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
------------------------------------------------------------------
= 0700000000000000000000000000000000000000000000000000000000000040

剩下的差異似乎歸結為規範化。特別是，RFC 7748 § 5說（強調我的）：

對於 X25519，為了將 32 個隨機字節解碼為整數標量，將第一個字節的三個最低有效位和最後一個字節的最高有效位設置為零，將最後一個字節的第二個最高有效位設置為 1，並且，最後，解碼為 little-endian。

Josefsson 草案中給出的S_a值似乎已經正確地預先應用了這種規範化（即在考慮字節反轉之後），而aRFC 7748 § 6.1 中的值將第一個字節的三個最低有效位設置為一個，最後一個字節的第二個最高有效位設置為零。

或者，人們可以簡單地將其解釋為aRFC 7748 § 6.1 中的 32 個隨機字節的原始輸入序列（寫為 32 對連接在一起的十六進制數字），而S_a來自 Josefsson 草案的是相應的 256 位數字（寫為十六進制整數文字）在這些隨機字節已按上述規範化並以小端順序解碼後獲得。

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