帶有 SHA256 和 sepc192r1 曲線的 ECDSA：不可能，或者如何計算和和e?

我需要使用 ECDSA 作為簽名算法並使用 SHA256 來散列消息。我在驗證在兩個不同平台上計算的簽名時遇到了麻煩（一個是 BouncyCastle，另一個是微處理器的 C 庫）。

我發現 BouncyCastle 在其 ECDSASigner 類中減少了輸入消息（應該已經是雜湊），在兩者中，generateSignature()並verifySignature()使用名為calculateE(). 本質上，此函式將輸入消息/散列截斷為曲線順序的位長 $ N $ .

protected BigInteger calculateE(BigInteger n, byte[] message)
{
   int log2n = n.bitLength();
   int messageBitLength = message.length * 8;

   BigInteger e = new BigInteger(1, message);
   if (log2n < messageBitLength)
   {
       e = e.shiftRight(messageBitLength - log2n);
   }
   return e;
}

這種減少是由於 SHA256 散列有 32 個字節，而 $ N $ 是（對於 secp192r1）192/8 = 24字節。

我不明白的是：

1. 我是否必須使用更大尺寸的曲線bitlength(N)來簽名 SHA256 雜湊（例如，secp256r1 或 secp521r1）？
2. BouncyCastle 中的實現是錯誤的/不完整的，還是僅適用於 SHA-1 ( 160 b = 20 B <= 24 B)？
3. 它在哪裡記錄/指定，如何*“減少”*比特長度大於曲線域的雜湊？

NIST FIPS 186-4在第 6.4 節末尾指出：

當雜湊函式的輸出長度大於 $ n $ , 然後最左邊 $ n $ 在生成或驗證數字簽名期間，散列函式輸出塊的比特應用於使用散列函式輸出的任何計算。

在第 6.1 節中，他們定義 $ n $ 作為生成器的順序，這使得措辭

最左邊 $ n $ 位

錯誤的。雖然很明顯，它們的意思是 $ n $ .

意思是：

1. 你不需要更大的曲線
2. BouncyCastle 實現看起來正確

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