SM2-kryptering / -dekryptering / signering

Hela SM2-verktygslådan för publika nycklar på den rekommenderade kurvan sm2p256v1 (GB/T 32918.5): generera ett nyckelpar, signera och verifiera med det SM3-baserade ZA-schemat (GB/T 32918.2), och kryptera eller dekryptera i standardordningen C1C3C2, den äldre ordningen C1C2C3, eller ASN.1 DER. Allt körs i webbläsaren; inget laddas upp.
1. Nycklar - generera ett par, eller klistra in ett eget (hex)
Privat nyckel (hex, 64 siffror — behandla som ett lösenord)
Publik nyckel (hex, 130 siffror med prefixet 04 eller 128 siffror x||y)
Den privata nyckeln används av Signera och Dekryptera; den publika av Verifiera och Kryptera. Nycklar lämnar aldrig sidan.
2. Signera - kräver den privata nyckeln; GB/T 32918.2 (SM3 + ZA)
Användar-ID("särskiljande identifieraren" som blandas in i ZA; standard är den de facto-standarden)
Läs meddelandet som: Fast k (avancerat):
r (hex)
s (hex)
Signatur, ASN.1 DER (SEQUENCE { r INTEGER, s INTEGER } - formatet som OpenSSL/GmSSL använder)
Om rutan för fast k: varje verklig signatur måste använda ett nytt, oförutsägbart k — att återanvända eller gissa k läcker den privata nyckeln (lärdomen från Sony ECDSA). Den här sidan genererar ett slumpmässigt k från crypto.getRandomValues när rutan är tom. Fyll i rutan endast för att återskapa en känd vektor i undervisning eller test.
3. Verifiera - kräver den publika nyckeln
Användar-ID(måste matcha signerarens)
Läs meddelandet som: Signaturformat:
r (hex)
s (hex)
✓ Signaturen är GILTIG
✗ Signaturen är OGILTIG
4. Kryptera - kräver den publika nyckeln; GB/T 32918.4
Läs meddelandet som: Chiffertextformat: Utdata:
Fast k (avancerat):
Påminnelse om hybridkryptering: SM2-kryptering är avsedd för korta hemligheter (sessionsnycklar, PIN-koder), inte massdata — varje meddelande betalar 96 byte C1+C3-overhead och en punktmultiplikation på en elliptisk kurva. Kryptera en slumpmässig SM4/AES-nyckel med SM2, sedan datan med den symmetriska chiffret (SM4-sidan / AES-sidan).
5. Dekryptera - kräver den privata nyckeln
Läs chiffertexten som: Ordning: Skriv klartexten som:
OpenSSL-korskontroll — den här sidans C1C3C2-hex matchar openssl pkeyutl -sm2encrypt -pubin -inkey pub.pem (OpenSSL 3.x med -pkeyopt ec_scheme:c1c3c2, standard), och GmSSL-verktygen gmssl sm2randkey / sm2encrypt; signaturer matchar openssl dgst -sm3 -sign med samma användar-ID via -pkeyopt sm2_userid:1234567812345678. En inledande 04-byte före C1 (som flera bibliotek producerar) accepteras vid dekryptering.
Efterlevnadsnotering: SM2 är ett algoritmval som styrs av kinesisk kommersiell kryptografi-efterlevnad och interoperabilitet, med säkerhet jämförbar med 256-bitars ECC (NIST P-256). I produktion, kombinera den med ett riktigt nyckelhanteringssystem eller hårdvarunycklar — en webbläsarsida är en räknare, inte ett valv.
Självtest
Spelar upp nyckelhärlednings-, fast-k-signatur- och krypteringsvektorerna som produceras av en oberoende Python-referensimplementation (och korskontrollerade mot gmssl), DER-signatur- och DER-chiffertextrundresorna, rundresor för slumpmässigt k-signering/verifiering och kryptering/dekryptering, samt de negativa vägarna (manipulerad C3, avkortad chiffertext, publik nyckel utanför kurvan, r = 0).
Vad är SM2?
Med en mening: SM2 är det kinesiska nationella standardsystemet för publik nyckel — ett elliptiskt kurvbaserat signatur- och krypteringsschema över den fasta kurvan sm2p256v1, publicerat som GB/T 32918-2016 (tidigare GM/T 0003-2012), och spelar i den kinesiska "SM"-sviten samma roll som ECDSA/ECDH (P-256) spelar i NIST-världen.
ECC i ett stycke (intuitionen)

All elliptisk-kurvkryptografi vilar på ett trick: givet basen G på en kurva över ett stort primtalsfält och multipeln P = d·G, innebär det att beräkna d från P att lösa det elliptiska-kurvans diskreta logaritmproblem, för vilket ingen snabb algoritm är känd. Den privata nyckeln d är bara ett 256-bitars tal; den publika nyckeln är punkten d·G. SM2 är inte någon ny kurvaritmetik — det är ett specifikt sätt att signera (likt ECDSA) och kryptera (likt en miniatyr-ECIES) på en specifik kurva, med hashning via SM3 i stället för SHA.

sm2p256v1 kontra NIST P-256
Aspektsm2p256v1NIST P-256 (secp256r1)
Fältstorlek256-bitars primtal256-bitars primtal
Kurvans formy² = x³ + ax + by² = x³ − 3x + b (a = −3)
Säkerhetsnivå≈ 128 bitar≈ 128 bitar
SignaturSM2 (GB/T 32918.2), SM3-baserad, användar-ID bundet i ZAECDSA med SHA-256
KrypteringSM2 (GB/T 32918.4), C1C3C2ECIES (ANSI X9.63, inte NIST-standardiserad)
HashSM3 (GB/T 32905)SHA-2-familjen
Publiceraddesignad 2010, GM/T 0003-2012, GB/T 32918-2016; i ISO/IEC 14888-31999 (SEC 2 / NIST)
TLS-stödTLCP (GM/T 386) och TLS 1.3-sviterna i RFC 8998överallt

Båda kurvorna erbjuder samma konkreta säkerhet; ingen har en praktisk attack. Valet mellan dem är regulatoriskt och en fråga om interoperabilitet, inte styrka.

Användar-ID:t och ZA — det SM2 signerar som ECDSA inte gör

Innan hashning viker SM2 in signerarens identitet i sammandraget: ZA = SM3(ENTL ‖ ID ‖ a ‖ b ‖ xG ‖ yG ‖ xA ‖ yA), där ENTLa är ID:ts bitlängd, de fyra mittfälten fastställer exakt kurvan, och de två sista är signerarens publika nyckel. Meddelandet hashas som SM3(ZA ‖ M). Två konsekvenser: en signatur är bunden till den påstådda identiteten (en egenskap), och verifieraren måste få veta signerarens ID och använda samma (en klassisk interoperabilitetsfälla). Nästan hela ekosystemet har landat på standard-ID:t 1234567812345678 — inte från standardens text, utan från bilagans exempel i GM/T 0003; OpenSSL:s standard matchar, och så gör denna sida.

Chiffertextformat: C1C3C2, C1C2C3 och DER

En SM2-chiffertext har tre delar: C1 = den temporära punkten kG (64 byte, x‖y), C3 = SM3(x2 ‖ M ‖ y2) (32 byte, integritet), C2 = M ⊕ KDF(x2 ‖ y2) (det maskerade meddelandet). Texten från 2012 års GM/T 0003 sammanfogade dem C1 ‖ C2 ‖ C3; 2016 års standard GB/T 32918.4 ordnade om till C1 ‖ C3 ‖ C2, och OpenSSL 1.1.1+ följde. Äldre bank- och myndighetssystem talar fortfarande den gamla ordningen — varför den här sidan har båda, plus ASN.1-formen (SEQUENCE av INTEGER x1, INTEGER y1, OCTET STRING C3, OCTET STRING C2) som vissa bibliotek producerar. När dekrypteringen misslyckas med den andra partens verktyg är byteordningen det första att kontrollera.

Vanliga misstag
  • Återanvändning av eller snålhet med k. Nonce k vid både signering och kryptering måste vara ny och oförutsägbar per operation. Ett upprepat k över två signaturer ger den privata nyckeln till vem som helst som ser båda. Den här sidan drar k från webbläsarens CSPRNG; rutorna för fast k finns endast för att återskapa kända vektorer.
  • Felaktiga användar-ID:n. Signerar man med standard-ID och verifierar med ett eget (eller tvärtom) misslyckas varje giltig signatur. ID:t är en del av den signerade datan.
  • Att anta C1C3C2 överallt. System från GM/T 0003-eran, vissa smarta kort och äldre GmSSL-byggen använder C1C2C3 som standard; flera verktyg lägger också till en okomprimerad punkt-byte 04 före. Den här sidan accepterar alla dessa vid dekryptering.
  • Att kryptera massdata med SM2. Varje chiffertext bär 96 byte overhead och kostar två punktmultiplikationer. Använd SM2 för en nyckel, SM4/AES för datan.
  • Att behandla en publik nyckel med prefixet 04 som 65 råa byte nyckel. 04 är en kodningsmarkör: nyckeln i sig är x ‖ y, 128 hexsiffror. Den här sidan accepterar båda stavningarna.
Vanliga frågor

Är detta kompatibelt med OpenSSL / GmSSL? Ja. C1C3C2-hex-utdatan matchar openssl pkeyutl -sm2encrypt för samma publika nyckel, meddelande och k; DER-signaturer matchar openssl dgst -sm3 -sign-utdata byte för byte (ange användar-ID med -pkeyopt sm2_userid:...). Körningar med slumpmässigt k skiljer sig förstås — jämför genom att dekryptera/verifiera, inte genom likhet.

Varför finns ingen SM2-nyckelutbyte här? GB/T 32918.3 definierar ett interaktivt autentiserat nyckelutbytesprotokoll; det är meningslöst som en enkel räknare. Signera och kryptera täcker de icke-interaktiva användningarna.

Finns SM2 i WebCrypto? Nej — ingen webbläsare implementerar det (Chrome levererar det endast bakom icke-standardiserade flaggor, om alls). Den här sidan kör en implementation i JavaScript skriven från grunden, med standardens egna bilagevektorer kopplade till självtestet ovan.

Kan jag använda en PEM-nyckel från OpenSSL? Exportera den råa hex i stället: openssl ec -in key.pem -text skriver ut den privata skalären och den publika punkten. Den här sidan tar endast hex-nycklar, avsiktligt — PEM/SEC1-mekaniken hör hemma på RSA-sidan, där den hör hemma.

Vad är då SM9? Ett annat djur: identitetsbaserad kryptografi, där en valfri sträng (en e-postadress) är den publika nyckeln och en KGC utfärdar privata nycklar. Se SM9-översiktssidan.