SM2-kryptering / -dekryptering / -signering

Den fulde SM2-værktøjskasse til offentlige nøgler på den anbefalede kurve sm2p256v1 (GB/T 32918.5): generér et nøglepar, signér og verificér med det SM3-baserede ZA-skema (GB/T 32918.2), og kryptér eller dekryptér i standardrækkefølgen C1C3C2, den ældre rækkefølge C1C2C3 eller ASN.1 DER. Alt kører i browseren; intet uploades.
1. Nøgler — generér et par, eller indsæt en egen (hex)
Privat nøgle (hex, 64 cifre — behandl den som en adgangskode)
Offentlig nøgle (hex, 130 cifre med 04-præfiks eller 128 cifre x||y)
Den private nøgle bruges af Signér og Dekryptér; den offentlige nøgle af Verificér og Kryptér. Nøgler forlader aldrig denne side.
2. Signér — kræver den private nøgle; GB/T 32918.2 (SM3 + ZA)
Bruger-ID(den "særskillende identifikator", der blandes ind i ZA; standard er den de facto-standard)
Læs besked som: Fast k (avanceret):
r (hex)
s (hex)
Signatur, ASN.1 DER (SEQUENCE { r INTEGER, s INTEGER } — formatet OpenSSL/GmSSL bruger)
Om boksen med fast k: hver rigtig signatur skal bruge en frisk, uforudsigelig k — genbrug eller gætning af k lækker den private nøgle (lektien fra Sony-ECDSA). Denne side genererer en tilfældig k fra crypto.getRandomValues, når boksen er tom. Udfyld kun boksen for at gengive en kendt vektor til undervisning eller test.
3. Verificér — kræver den offentlige nøgle
Bruger-ID(skal matche signatørens)
Læs besked som: Signaturformat:
r (hex)
s (hex)
✓ Signaturen er GYLDIG
✗ Signaturen er UGYLDIG
4. Kryptér — kræver den offentlige nøgle; GB/T 32918.4
Læs besked som: Ciphertext-format: Output:
Fast k (avanceret):
Påmindelse om hybridkryptering: SM2-kryptering er beregnet til korte hemmeligheder (sessionsnøgler, PIN-koder), ikke store datamængder — hver besked betaler 96 byte C1+C3-overhead og en multiplikation af elliptiske kurvepunkter. Kryptér en tilfældig SM4/AES-nøgle med SM2, og derefter dataene med den symmetriske chiffer (SM4-siden / AES-siden).
5. Dekryptér — kræver den private nøgle
Læs ciphertext som: Orden: Skriv klartekst som:
OpenSSL-krydstjek — denne sides C1C3C2-hex matcher openssl pkeyutl -sm2encrypt -pubin -inkey pub.pem (OpenSSL 3.x med -pkeyopt ec_scheme:c1c3c2, standarden), og GmSSL-værktøjerne gmssl sm2randkey / sm2encrypt; signaturer matcher openssl dgst -sm3 -sign med samme bruger-ID via -pkeyopt sm2_userid:1234567812345678. En førende 04-byte før C1 (som flere biblioteker producerer) accepteres ved dekryptering.
Overensstemmelsesnote: SM2 er et algoritmevalg drevet af kinesisk kommerciel kryptografi-overensstemmelse og interoperabilitet, med en sikkerhed, der kan sammenlignes med 256-bit ECC (NIST P-256). I produktion bør den parres med et rigtigt nøglestyringssystem eller hardwarenøgler — en browserside er en lommeregner, ikke et hvælvinger.
Selvtest
Gentager nøgleafledning-, fast-k-signatur- og krypteringsvektorerne, produceret af en uafhængig Python-referenceimplementering (og krydstjekket mod gmssl), DER-signatur- og DER-ciphertext-rundturene, rundture med tilfældig k for signér/verificér og kryptér/dekryptér, samt de negative stier (manipuleret C3, afkortet ciphertext, offentlig nøgle uden for kurven, r = 0).
Hvad er SM2?
I én sætning: SM2 er det kinesiske nationale standard-offentlig-nøgle-kryptosystem — et elliptisk-kurve-signatur- og krypteringsskema over den faste kurve sm2p256v1, offentliggjort som GB/T 32918-2016 (tidligere GM/T 0003-2012), og det spiller den rolle i den kinesiske "SM"-pakke, som ECDSA/ECDH (P-256) spiller i NIST-verdenen.
ECC på ét afsnit (intuitionen)

Al elliptisk-kurve-kryptografi hviler på ét trick: givet basispunktet G på en kurve over et stort primtalsfelt og multiplen P = d·G, kræver det at beregne d ud fra P at løse det elliptiske-kurve-diskrete-logaritmeproblem, og der kendes ingen hurtig algoritme til det. Den private nøgle d er blot et 256-bit tal; den offentlige nøgle er punktet d·G. SM2 er ikke en ny kurvearitmetik — det er en bestemt måde at signere (ligesom ECDSA) og kryptere (ligesom en miniature-ECIES) på én bestemt kurve, med hashing via SM3 i stedet for SHA.

sm2p256v1 kontra NIST P-256
Egenskabsm2p256v1NIST P-256 (secp256r1)
Feltstørrelse256-bit primtal256-bit primtal
Kurveformy² = x³ + ax + by² = x³ − 3x + b (a = −3)
Sikkerhedsniveau≈ 128 bit≈ 128 bit
SignaturSM2 (GB/T 32918.2), SM3-baseret, bruger-ID bundet ind i ZAECDSA med SHA-256
KrypteringSM2 (GB/T 32918.4), C1C3C2ECIES (ANSI X9.63, ikke NIST-standardiseret)
HashSM3 (GB/T 32905)SHA-2-familien
Offentliggjort2010-design, GM/T 0003-2012, GB/T 32918-2016; i ISO/IEC 14888-31999 (SEC 2 / NIST)
TLS-understøttelseTLCP (GM/T 386) og TLS 1.3 RFC 8998-pakkerneoveralt

Begge kurver tilbyder samme konkrete sikkerhed; ingen har et praktisk angreb. Valget mellem dem handler om regulering og interoperabilitet, ikke styrke.

Bruger-ID'et og ZA — hvad SM2 signerer, som ECDSA ikke gør

Før hashing folder SM2 signatørens identitet ind i digest'en: ZA = SM3(ENTL ‖ ID ‖ a ‖ b ‖ xG ‖ yG ‖ xA ‖ yA), hvor ENTLa er ID'ets bitlængde, de fire midterste felter fastlåser den præcise kurve, og de sidste to er signatørens offentlige nøgle. Beskeden hashes som SM3(ZA ‖ M). To konsekvenser: en signatur er bundet til den påståede identitet (en egenskab), og verifikatoren skal fortælles signatørens ID og bruge det samme (en klassisk interop-fælde). Næsten hele økosystemet landede på det 16-cifrede standard-ID 1234567812345678 — ikke fra standardens tekst, men fra appendiks-eksemplerne i GM/T 0003; OpenSSLs standard matcher det, og det gør denne side også.

Ciphertext-formater: C1C3C2, C1C2C3 og DER

En SM2-ciphertext har tre dele: C1 = det midlertidige punkt kG (64 byte, x‖y), C3 = SM3(x2 ‖ M ‖ y2) (32 byte, integritet), C2 = M ⊕ KDF(x2 ‖ y2) (den maskerede besked). Teksten fra 2012 (GM/T 0003) sammenkædede dem C1 ‖ C2 ‖ C3; standarden fra 2016 (GB/T 32918.4) omordnede til C1 ‖ C3 ‖ C2, og OpenSSL 1.1.1+ fulgte. Gamle bank- og statssystemer taler stadig den gamle rækkefølge — derfor har denne side begge, plus ASN.1-formen (SEQUENCE af INTEGER x1, INTEGER y1, OCTET STRING C3, OCTET STRING C2), som nogle biblioteker producerer. Når dekryptering fejler med den anden parts værktøj, er bytes-rækkefølgen det første, der skal tjekkes.

Almindelige fejl
  • Genbrug af eller snyd med k. Nonce'en k i både signering og kryptering skal være frisk og uforudsigelig for hver operation. En gentaget k på tværs af to signaturer giver den private nøgle til enhver, der ser begge. Denne side trækker k fra browserens CSPRNG; boksene med fast k findes kun til at gengive kendte vektorer.
  • Uoverensstemmende bruger-ID'er. Signér med standard-ID'et, og verificér med et brugerdefineret (eller omvendt), og enhver gyldig signatur fejler. ID'et er en del af de signerede data.
  • At antage C1C3C2 overalt. Systemer fra GM/T 0003-tiden, nogle smartkort og ældre GmSSL-builds bruger som standard C1C2C3; flere værktøjer sætter også en ukomprimeret punkt-04-byte foran. Denne side accepterer alle disse ved dekryptering.
  • At kryptere store datamængder med SM2. Hver ciphertext bærer 96 byte overhead og koster to punktmultiplikationer. Brug SM2 på en nøgle, SM4/AES på dataene.
  • At behandle en offentlig nøgle med 04-præfiks som 65 rå bytes nøgle. 04 er en kodningsmarkør: selve nøglen er x ‖ y, 128 hex-cifre. Denne side accepterer begge stavemåder.
Ofte stillede spørgsmål

Er dette kompatibelt med OpenSSL / GmSSL? Ja. C1C3C2-hex-outputtet matcher openssl pkeyutl -sm2encrypt for samme offentlige nøgle, besked og k; DER-signaturer matcher openssl dgst -sm3 -sign-output byte for byte (sæt bruger-ID'et med -pkeyopt sm2_userid:...). Kørsler med tilfældig k adskiller sig naturligvis — sammenlign ved at dekryptere/verificere, ikke ved lighed.

Hvorfor er der ingen SM2-nøgleudveksling her? GB/T 32918.3 definerer en interaktiv, autentificeret nøgleudvekslingsprotokol; den giver ingen mening som en lommeregner på én side. Signér og kryptér dækker de ikke-interaktive anvendelser.

Er SM2 i WebCrypto? Nej — ingen browser implementerer det (Chrome leverer det kun bag ikke-standard flag, hvis overhovedet). Denne side kører en implementering i JavaScript skrevet fra bunden, med standardens egne appendiks-vektorer koblet ind i selvtesten ovenfor.

Kan jeg bruge en PEM-nøgle fra OpenSSL? Eksportér i stedet den rå hex: openssl ec -in key.pem -text udskriver den private skalar og det offentlige punkt. Denne side tager kun hex-nøgler, med vilje — PEM/SEC1-maskineriet hører hjemme på RSA-siden, hvor det hører til.

Hvad er SM9 så? Et andet dyr: identitetsbaseret kryptografi, hvor en vilkårlig streng (en e-mailadresse) er den offentlige nøgle, og en KGC udsteder private nøgler. Se SM9-oversigtssiden.