簡(jiǎn)介這是一份演示橢圓曲線數(shù)字簽名算法ECDSA的工程代碼包面向C開發(fā)者或密碼學(xué)初學(xué)者展示如何借助Crypto庫(kù)完成密鑰生成、簽名與驗(yàn)證的全流程。資源共39個(gè)文件壓縮包8.91MB以cpp源文件、頭文件、Visual Studio工程文件sln/vcxproj/dsw為主同時(shí)包含可執(zhí)行exe與調(diào)試生成的obj、pdb等并附帶少量gif動(dòng)圖、日志和升級(jí)報(bào)告文件既可用于直接學(xué)習(xí)和復(fù)現(xiàn)簽名流程也方便在VS環(huán)境中重新編譯與調(diào)試。已有470人學(xué)習(xí)瀏覽。代碼包基于NIST P-256等曲線演示了從隨機(jī)數(shù)生成密鑰對(duì)、哈希待簽名消息到輸出R、S簽名分量以及用公鑰驗(yàn)簽的典型實(shí)現(xiàn)工程內(nèi)項(xiàng)目文件與目錄結(jié)構(gòu)完整適合希望落地ECDSA算法的開發(fā)者作為參考模板快速嵌入自身安全通信或區(qū)塊鏈相關(guān)項(xiàng)目中。1. 為什么 ECDSA簽名算法 總在“驗(yàn)證失敗”上翻車拿到一個(gè)叫 ECDSA-Test.rar 的壓縮包打開一看是簽名算法的測(cè)試代碼這幾乎是所有接觸 ECDSA 的人都經(jīng)歷過的場(chǎng)景簽名能跑通換一臺(tái)機(jī)器或者換一個(gè)語言驗(yàn)證就失敗。這不是代碼抄錯(cuò)了而是 ECDSA 對(duì)“參數(shù)一致性”的敏感程度遠(yuǎn)超直覺。同樣的私鑰、同樣的消息攻擊算一次一個(gè)樣子DER 編碼、哈希算法、r/s 順序、曲線參數(shù)任何一處對(duì)不上驗(yàn)簽結(jié)果就是 false。ECDSA 的全稱是 Elliptic Curve Digital Signature Algorithm它依賴橢圓曲線離散對(duì)數(shù)難題用私鑰對(duì)消息摘要簽名公鑰驗(yàn)簽。跟 RSA 相比它的簽名短、性能好但對(duì)實(shí)現(xiàn)細(xì)節(jié)極其挑剔。這篇文章會(huì)從橢圓曲線選型、參數(shù)計(jì)算、DER 編碼、隨機(jī)數(shù) k 的處理到驗(yàn)證排錯(cuò)把 ECDSA 簽名算法 在落地時(shí)最容易踩的坑全部過一遍讓新手能跑通最小示例讓熟手能定位跨庫(kù)互操作問題。2. ECDSA 由什么組成曲線、哈希與簽名結(jié)構(gòu)2.1 ECDSA 與 RSA 的根本差異ECDSA 的簽名長(zhǎng)度取決于曲線的“階”也就是橢圓曲線上的點(diǎn)的個(gè)數(shù) n 的二進(jìn)制位數(shù)。n 是 256 位時(shí)r 和 s 各自不超過 32 字節(jié)DER 編碼后的簽名通常在 7072 字節(jié)。RSA 的簽名長(zhǎng)度等于模長(zhǎng)位數(shù)2048 位 RSA 的簽名總是 256 字節(jié)。這個(gè)差距在物聯(lián)網(wǎng)設(shè)備、區(qū)塊鏈交易和證書場(chǎng)景里非常明顯。另一個(gè)差異是隨機(jī)數(shù)。RSA 簽名是確定性的同樣的私鑰和消息簽名結(jié)果永遠(yuǎn)一樣。ECDSA 則不然它每一步計(jì)算都依賴一個(gè)隨機(jī)數(shù) k。k 一旦泄露私鑰就能被直接算出來k 如果重復(fù)使用兩次攻擊者在只有兩個(gè)簽名樣本的情況下就能恢復(fù)私鑰。這是 ECDSA 最常見的安全事故來源后面第 4 章會(huì)專門展開講。2.2 簽名結(jié)果不是密文r、s 與 DER 編碼很多人第一次驗(yàn)簽失敗是因?yàn)榘押灻?dāng)成固定字節(jié)序列去比較。實(shí)際上 ECDSA 的簽名是一個(gè)結(jié)構(gòu)體(r, s)r 是臨時(shí)公鑰點(diǎn)的 x 坐標(biāo)對(duì) n 取模的余數(shù)s 是私鑰參與計(jì)算的另一個(gè)整數(shù)。DER 編碼只是序列化方式不是加密任何能解析 ASN.1 的工具都能把 r 和 s 拆出來。DER 簽名的格式遵循 ECDSA-Sig-Value簽名內(nèi)容本身不會(huì)被哈希它只是 r、s 兩個(gè)大整數(shù)按 ASN.1 規(guī)則編碼后的字節(jié)串。r 或 s 的最高位字節(jié)如果大于等于 0x80需要在前面補(bǔ)一個(gè) 0x00否則編碼出來會(huì)是負(fù)數(shù)。這一條規(guī)則就是無數(shù)跨語言驗(yàn)簽失敗的根源。2.3 用 Python 生成 ECDSA 密鑰并簽名的最小代碼我一般會(huì)建議用 Python 的cryptography庫(kù)做本地驗(yàn)證因?yàn)樗?API 直白且 DER 編碼是自動(dòng)處理的。下面的代碼生成一個(gè) P-256 曲線密鑰對(duì)一段消息做簽名然后立即驗(yàn)簽。from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import utils # 生成 P-256 曲線密鑰對(duì) private_key ec.generate_private_key(ec.SECP256R1()) public_key private_key.public_key() message bECDSA Test Vector # 直接對(duì)原始消息簽名庫(kù)內(nèi)部會(huì)先計(jì)算 SHA-256 signature private_key.sign(message, ec.ECDSA(hashes.SHA256())) # 驗(yàn)簽簽名成功返回 None失敗拋出異常 try: public_key.verify(signature, message, ec.ECDSA(hashes.SHA256())) print(簽名驗(yàn)證通過) except Exception as e: print(f驗(yàn)證失敗: {e})這里的ec.ECDSA(hashes.SHA256())指定簽名算法是 ECDSA且哈希函數(shù)為 SHA-256。private_key.sign()會(huì)把原始消息做哈希再執(zhí)行 ECDSA 內(nèi)部運(yùn)算最后輸出 DER 編碼后的字節(jié)串。public_key.verify()會(huì)先解析 DER、還原 r 和 s重新計(jì)算哈希后做驗(yàn)簽。注意如果把簽名丟給只支持裸 r/s 的接口就必須先解析 DER不能直接傳字節(jié)。常見的國(guó)密場(chǎng)景會(huì)用到 SM2但 SM2 與 ECDSA 的公式和哈希預(yù)處理不同NIST 曲線和 SM2 曲線不要混用。2.4 常見曲線的參數(shù)差異曲線選型決定了簽名長(zhǎng)度、性能和安全級(jí)別。下面是落地時(shí)最常遇到的曲線參數(shù)表n 的位數(shù)就是簽名的安全強(qiáng)度。曲線名稱密鑰長(zhǎng)度bit簽名長(zhǎng)度DER約安全強(qiáng)度bit典型場(chǎng)景secp256r1P-2562567072 字節(jié)128Web 證書、JWT、云服務(wù)secp256k12567072 字節(jié)128區(qū)塊鏈、比特幣類交易secp384r1P-384384104106 字節(jié)192高安全等級(jí)證書secp521r1P-521521139142 字節(jié)256軍工、金融加密機(jī)選曲線時(shí)要注意“廢棄曲線”問題。有一些曲線參數(shù)存在弱化風(fēng)險(xiǎn)不要為了跟某個(gè)老系統(tǒng)對(duì)齊而選擇過短的曲線?，F(xiàn)在的主流是 P-256 起步合規(guī)要求高的場(chǎng)景用 P-384。3. 驗(yàn)簽最容易踩的坑DER 編碼與 r/s 格式互轉(zhuǎn)3.1 用 cryptography 庫(kù)驗(yàn)簽的正確姿勢(shì)驗(yàn)簽失敗時(shí)第一件事是確認(rèn)簽名格式。cryptography庫(kù)默認(rèn)只接受 DER 編碼這在文檔里寫得很清楚但很多人從網(wǎng)上復(fù)制代碼時(shí)直接拿十六進(jìn)制字符串往verify()里塞然后就報(bào)InvalidSignature。正確的驗(yàn)簽姿勢(shì)是先把十六進(jìn)制解碼成字節(jié)再看這個(gè)字節(jié)串是不是合法的 DER。DER 開頭是 0x30也就是 ASN.1 的 SEQUENCE 標(biāo)記。如果字節(jié)串開頭不是 0x30那大概率是裸 r/s 拼接格式可以先把它包裝成 DER 再做驗(yàn)證。import binascii from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import hashes public_key ... # 之前生成或加載的公鑰 # 假設(shè)拿到了兩種格式的簽名 der_hex 3045022100... raw_hex 5c81ac89fd2d2d0f31d7fe49e1ecf3a15e1a8c7f50d34f53c66dcd24221ca0 der_sig binascii.unhexlify(der_hex) # 裸 r/s 轉(zhuǎn) DER 需要先拆分 r 和 s r_hex raw_hex[:64] s_hex raw_hex[64:] r_int int(r_hex, 16) s_int int(s_hex, 16) from cryptography.hazmat.primitives.asymmetric.utils import encode_dss_signature der_from_raw encode_dss_signature(r_int, s_int) for label, sig in [(DER 原始, der_sig), (raw 轉(zhuǎn)換, der_from_raw)]: try: public_key.verify(sig, bECDSA Test Vector, ec.ECDSA(hashes.SHA256())) print(f{label} 驗(yàn)簽通過) except Exception as e: print(f{label} 驗(yàn)簽失敗: {e})這里的encode_dss_signature(r, s)就是官方提供的 r/s 轉(zhuǎn) DER 工具函數(shù)它可以避免你手寫 ASN.1 結(jié)構(gòu)時(shí)漏掉前導(dǎo)零字節(jié)。相應(yīng)地decode_dss_signature(der_sig)可以把 DER 拆回 r 和 s 兩個(gè)整數(shù)。3.2 DER 與 raw 簽名互轉(zhuǎn)跨庫(kù)互操作的關(guān)鍵不同生態(tài)對(duì)簽名格式的默認(rèn)值不同。區(qū)塊鏈生態(tài)偏愛 raw 格式也就是 r 和 s 各占固定 32 字節(jié)共 64 字節(jié)安全庫(kù)和證書體系則默認(rèn) DER。兩個(gè)系統(tǒng)在對(duì)接時(shí)如果格式?jīng)]對(duì)齊驗(yàn)簽必然失敗。格式結(jié)構(gòu)長(zhǎng)度P-256典型生態(tài)DERASN.1 SEQUENCE 編碼7072 字節(jié)OpenSSL、Java、.NET、Go 標(biāo)準(zhǔn)庫(kù)raw r/sr 和 s 各 n 位左填充 0 到定長(zhǎng)64 字節(jié)以太坊、比特幣、部分區(qū)塊鏈 SDKJOSE 風(fēng)格base64url 編碼的 raw r/s86 字符左右JWS、COSE、WebAuthnJava 的Signature類默認(rèn)輸出 DER而很多區(qū)塊鏈 SDK 只認(rèn) raw。如果從 Web3 的 RPC 接口拿簽名驗(yàn)簽先把它切成 r 和 s 再做轉(zhuǎn)換。切的時(shí)候要從末尾往前數(shù)因?yàn)?DER 的 s 長(zhǎng)度可能和 r 不同但 raw 格式下 r 和 s 等長(zhǎng)。3.3 驗(yàn)簽失敗后你最先該查的四個(gè)點(diǎn)按出現(xiàn)頻率排序驗(yàn)簽失敗通常是這四種情況哈希算法不一致簽名方用了 SHA-1驗(yàn)簽方用 SHA-256r/s 對(duì)不上。編碼格式不對(duì)簽名方輸出 raw驗(yàn)簽方按 DER 解析解析直接拋異常。公鑰不匹配多環(huán)境部署時(shí)加載了舊的公鑰文件。消息內(nèi)容不一致消息在傳輸過程中被加了換行符、空格或 base64 解碼錯(cuò)誤。排查時(shí)我會(huì)先打印signature.hex()和public_key.public_numbers().x這類關(guān)鍵信息做人工比對(duì)再逐步縮小范圍。用下面的邏輯順序去查效率最高。# 先看簽名格式開頭必須是 30 xxd signature.bin | head -n 1 # 再看簽名長(zhǎng)度P-256 的 DER 在 7072 字節(jié) wc -c signature.bin # 對(duì)比哈希值 openssl dgst -sha256 -binary message.txt | xxdxxd顯示的首個(gè)字節(jié)如果不是30就說明簽名格式不是 DER長(zhǎng)度不對(duì)則可能是 r/s 拼接錯(cuò)誤。哈希值對(duì)比可以幫助排除消息內(nèi)容差異。OpenSSL 命令里-binary是取原始二進(jìn)制摘要避免文本模式的換行污染。4. ECDSA 的工程邊界隨機(jī)數(shù) k 的秘密與可復(fù)現(xiàn)測(cè)試4.1 隨機(jī)數(shù) k 一旦重復(fù)私鑰就會(huì)暴露ECDSA 的簽名方程涉及兩個(gè)私密值私鑰 d 和臨時(shí)隨機(jī)數(shù) k。消息的哈希是 z曲線階是 n簽名的 s k?1(z r × d) mod n。攻擊者如果能拿到兩個(gè)使用了同一個(gè) k 的簽名(r, s?)和(r, s?)那么 k (z? - z?) / (s? - s?) mod n然后可以用任何一條簽名方程解出 d。這個(gè)推導(dǎo)不需要任何密碼學(xué)背景初中代數(shù)就能完成。所以隨機(jī)數(shù) k 必須由安全的隨機(jī)數(shù)生成器產(chǎn)生絕對(duì)不能讓業(yè)務(wù)代碼自己寫一個(gè)偽隨機(jī)函數(shù)去拼 k。常見的錯(cuò)誤是拿時(shí)間戳做種子生成 k這在安全評(píng)審里屬于致命缺陷。所有主流密碼學(xué)庫(kù)都已經(jīng)內(nèi)置了安全的 k 生成邏輯直接用即可。4.2 用 RFC 6979 做確定性 ECDSA很多場(chǎng)景需要簽名可復(fù)現(xiàn)硬件錢包的固件回歸測(cè)試、區(qū)塊鏈節(jié)點(diǎn)的交易廣播重試、審計(jì)系統(tǒng)對(duì)歷史簽名的復(fù)查。ECDSA 默認(rèn)每次簽名結(jié)果不同這會(huì)給測(cè)試帶來麻煩。RFC 6979 就是用來解決這個(gè)問題的標(biāo)準(zhǔn)它從消息哈希加私鑰推導(dǎo)出確定性 k使得同一私鑰對(duì)同一消息的簽名永遠(yuǎn)一致。cryptography庫(kù)沒有直接暴露 RFC 6979 的開關(guān)但許多底層庫(kù)和語言 SDK 支持。Go 的crypto/ecdsa在SignASN1里已經(jīng)默認(rèn)使用類似 RFC 6979 的確定性邏輯C 的 OpenSSL 在 3.0 里通過 provider 可以提供確定性簽名實(shí)現(xiàn)。如果要自己實(shí)現(xiàn)核心思路是用 HMAC 迭代生成字節(jié)串再映射到 [1, n-1] 區(qū)間每一輪失敗就更新內(nèi)部的 V 值繼續(xù)生成。工程上不建議自己寫這個(gè)算法標(biāo)準(zhǔn)庫(kù)如果支持就直接用。4.3 哈希截?cái)嗖黄ヅ鋷淼陌踩[患ECDSA 內(nèi)部使用的哈希值要除以 n 的位數(shù)做截?cái)?。如果哈希輸出的位?shù)比 n 的位數(shù)長(zhǎng)比如 SHA-256256 位配 P-256n 也是 256 位不需要截?cái)嗟绻?SHA-384 配 P-256則只取哈希結(jié)果最左邊的 256 位。這個(gè)截?cái)嘁?guī)則在實(shí)現(xiàn)時(shí)很容易被忽略。截?cái)嗖皇呛?jiǎn)單的“取前 32 字節(jié)”而是取哈希輸出的最高有效位。具體來說將哈希結(jié)果視為一個(gè)比特串從左邊開始取 log2(n) 個(gè)比特。n 的位數(shù)通常不是 8 的整數(shù)倍所以取完后要除以 8余數(shù)位要右移舍棄。如果驗(yàn)簽方和簽名方截?cái)嘁?guī)則不一致簽名就會(huì)在邊界情況時(shí)反復(fù)失敗。4.4 在測(cè)試環(huán)境里搭建可復(fù)現(xiàn)的 ECDSA 測(cè)試臺(tái)測(cè)試 ECDSA 實(shí)現(xiàn)時(shí)建議用已知的標(biāo)準(zhǔn)測(cè)試向量做基線不要只依賴自己庫(kù)里生成的簽名。NIST 和 SECG 都公開了 P-256 的確定性測(cè)試向量每條包含私鑰、消息、隨機(jī)數(shù) k、r、s 和公鑰坐標(biāo)。驗(yàn)證步驟是先用固定 k 按 ECDSA 公式計(jì)算 r 和 s再手工驗(yàn)簽一次最后用標(biāo)準(zhǔn)庫(kù)驗(yàn)簽一次。這樣能把“算法實(shí)現(xiàn)正確”和“庫(kù)接口使用正確”分開驗(yàn)證。下面這個(gè) Python 腳本可以驗(yàn)證基礎(chǔ) ECDSA 運(yùn)算是否與標(biāo)準(zhǔn)庫(kù)一致import hashlib from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import utils # 測(cè)試向量數(shù)據(jù)這里僅做參數(shù)示意真實(shí)測(cè)試請(qǐng)?zhí)鎿Q為 NIST 文檔中的數(shù)值 d 0xC9AFA9D845BA75166B5C215767B1D6934E50C3DB36E89B127B8A622B120F6721 message bsample curve ec.SECP256R1() # 重建私鑰對(duì)象 priv ec.derive_private_key(d, curve) pub priv.public_key() # 標(biāo)準(zhǔn)庫(kù)簽名推薦用于接口正確性驗(yàn)證 sig priv.sign(message, ec.ECDSA(hashes.SHA256())) print(標(biāo)準(zhǔn)庫(kù)簽名:, sig.hex()) # 驗(yàn)證簽名結(jié)果 try: pub.verify(sig, message, ec.ECDSA(hashes.SHA256())) print(標(biāo)準(zhǔn)庫(kù)驗(yàn)簽通過) except Exception as e: print(驗(yàn)簽失敗:, e)derive_private_key的入?yún)⑹钦麛?shù)私鑰和曲線對(duì)象它會(huì)把私鑰映射到曲線點(diǎn)公鑰。注意測(cè)試向量里的 d 必須是 1 到 n-2 之間的整數(shù)否則密鑰本身就不合法。測(cè)試向量跑通后再用自己的實(shí)現(xiàn)去簽名對(duì)比 r 和 s 是否一致如果 r/s 不同但驗(yàn)簽通過說明你的實(shí)現(xiàn)里 k 的生成方式與預(yù)期不同但簽名方程正確可以接受。5. 讓 ECDSA 測(cè)試真正“可跑可信”的驗(yàn)證技巧最后分享一個(gè)能顯著減少調(diào)試時(shí)間的技巧在任何代碼里加入一條自檢斷言它會(huì)驗(yàn)證當(dāng)前公鑰是否位于正確的曲線之上。因?yàn)?ECDSA 驗(yàn)簽函數(shù)只做數(shù)學(xué)運(yùn)算不會(huì)主動(dòng)檢查公鑰點(diǎn)是否真的屬于該曲線。如果你傳入的公鑰是別的曲線上的點(diǎn)甚至是不在曲線上的點(diǎn)某些實(shí)現(xiàn)會(huì)直接拋異常但另一些實(shí)現(xiàn)會(huì)給出一個(gè)“驗(yàn)簽失敗”的結(jié)果這就非常難排查。所以在加載公鑰之后立刻用下面的公式做驗(yàn)證將公鑰 x、y 代入曲線方程檢查等式是否成立。def validate_point_on_curve(x, y, curve): p curve.curve.p a curve.curve.a b curve.curve.b # 檢查是否滿足 y^2 x^3 a*x b (mod p) left (y * y) % p right (x * x * x a * x b) % p return left right # 用法示例 pub priv.public_key() x pub.public_numbers().x y pub.public_numbers().y assert validate_point_on_curve(x, y, ec.SECP256R1()), 公鑰不在曲線上這段代碼用最直接的方式把坐標(biāo)代入了曲線方程其中p是素域模數(shù)a和b是曲線的形狀參數(shù)。P-256 的a是固定常數(shù)b有固定的標(biāo)準(zhǔn)值依賴庫(kù)對(duì)象直接讀取比自己在配置文件里寫死更可靠。類似地私鑰也需要檢查是否在合法區(qū)間 [1, n-2] 內(nèi)。寫完這層自檢之后再去對(duì)接任何 ECDSA 簽名算法接口失敗原因就會(huì)被收斂到真正的消息處理或編碼問題上。至此你已經(jīng)在本地?fù)碛辛艘粋€(gè)具備自檢、可復(fù)現(xiàn)、跨格式驗(yàn)證的 ECDSA 測(cè)試臺(tái)后續(xù)遇到任何簽名驗(yàn)證問題都可以按這套方法定位到具體環(huán)節(jié)。本文還有配套的精品資源點(diǎn)擊獲取