在 ECDSA 中使用不同的散列函式
我遇到了一個 IC 設備配置和安全流程，詳細資訊如下圖所示。我想知道 ECDSA 必須與 SHA 散列函式配對嗎？
或者，如果使用 AES-GCM 生成 CIPHER 和TAG怎麼辦？GF 生成的TAG之後經過 ECDSA 用私鑰加密。
因此，從解密方面來看，它的工作原理與圖像完全相同，只是用 AES-GCM 引擎替換了 SHA 引擎。我想知道為什麼這在所有行業實踐中都不常見？
或者我上面描述的方案會有什麼問題嗎？
我將首先解決圖表的問題；
加密部分
儘管提到加密是可選的
- 沒有提及如何生成 AES 密鑰。常用的方法是 Diffie-Hellman 密鑰交換，它的橢圓曲線版本是首選 ECDH。
- 沒有提及操作模式。CBC，點擊率，GCM，…等。
- 沒有提到 nonce/IV 代。隨機數生成至關重要；
- 在 CBC 中它必須是不可預測的
- 在 CTR 和 GCM 中，(IV,key) 對不應使用超過一次。
ECDSA部分；
- 命名是完全錯誤的。我們使用簽名和驗證，這些過程與加密和解密完全不同，即使在 RSA 中也是如此。簡而言之，RSA 解密不是簽名。
- 驗證部分錯誤。只發送簽名部分，ECDSA驗證過程中籤名和消息必須同時存在。他們傾向於使它對稱，但這是錯誤的。
問題
我想知道 ECDSA 必須與 SHA 散列函式配對嗎？
他們沒有顯示那裡使用了哪條曲線。如果使用像 P521 或 Goldilocks 這樣的曲線，則可能需要像 SHAKE128-512 系列這樣的 XOF，或者使用 SHA256 作為 CTR 模式來生成多個塊來支持所有曲線需求。
或者，如果使用 AES-GCM 同時生成 CIPHER 和 TAG 怎麼辦？GF 生成的 TAG 之後經過 ECDSA 用私鑰加密。
AES-GCM 不會產生數字簽名，只有在正確使用的情況下才能提供機密性、完整性和身份驗證。AES-GCM 不能提供不可否認性。對於數字簽名，您需要一個數字簽名算法。
或者我上面描述的方案會有什麼問題嗎？
如果不需要數字簽名，那就沒問題了。AES-GCM 有更好的選擇；AES-GCM-SIV 是一種防止隨機數誤用的方案。如果使用相同的 (key,IV) 對再次發送相同的消息，這只會洩漏再次發送相同的消息。
或者我上面描述的方案會有什麼問題嗎？
AES 密鑰是公開的嗎？如果是，那麼很容易生成兩條具有相同標籤的消息（因此會像衝突一樣）。
如果簽名者和驗證者都知道 AES 密鑰？如果是的話，那麼，為什麼還要為 ECDSA 操心呢？如果您有共享密鑰，您可以使用比 ECDSA（或任何其他公鑰簽名操作）效率更高的消息驗證碼（例如 HMAC、CMAC、GMAC）。