SM2-kryptering / -dekryptering / signering

Den fullstendige SM2-verktøykassen for den anbefalte kurven sm2p256v1 (GB/T 32918.5): generer et nøkkelpar, signer og verifiser med den SM3-baserte ZA-ordningen (GB/T 32918.2), og krypter eller dekrypter i standardrekkefølgen C1C3C2, den eldre rekkefølgen C1C2C3, eller ASN.1 DER. Alt kjøres i nettleseren; ingenting lastes opp.
1. Nøkler - generer et par, eller lim inn et eget (heks)
Privat nøkkel (heks, 64 sifre — behandle som et passord)
Offentlig nøkkel (heks, 130 sifre med 04-prefiks eller 128 sifre x||y)
Den private nøkkelen brukes av Signer og Dekrypter; den offentlige av Verifiser og Krypter. Nøkler forlater aldri denne siden.
2. Signer - krever den private nøkkelen; GB/T 32918.2 (SM3 + ZA)
Bruker-ID(den «særskilte identifikatoren» som blandes inn i ZA; standarden er de facto)
Les melding som: Fast k (avansert):
r (heks)
s (heks)
Signatur, ASN.1 DER (SEQUENCE { r INTEGER, s INTEGER } - formatet OpenSSL/GmSSL bruker)
Om boksen med fast k: hver ekte signatur må bruke en ny, uforutsigbar k — gjenbruk eller gjetning av k lekker den private nøkkelen (lærdommen fra Sony-ECDSA). Denne siden genererer en tilfeldig k fra crypto.getRandomValues når boksen er tom. Fyll bare inn boksen for å gjenskape en kjent vektor til undervisning eller testing.
3. Verifiser - krever den offentlige nøkkelen
Bruker-ID(må samsvare med signatørens)
Les melding som: Signaturformat:
r (heks)
s (heks)
✓ Signaturen er GYLDIG
✗ Signaturen er UGYLDIG
4. Krypter - krever den offentlige nøkkelen; GB/T 32918.4
Les melding som: Chiffertekstformat: Utdata:
Fast k (avansert):
Påminnelse om hybridkryptering: SM2-kryptering er ment for korte hemmeligheter (sesjonsnøkler, PIN-koder), ikke store datamengder — hver melding betaler 96 byte C1+C3-overhead og en multiplikasjon av elliptiske kurvepunkter. Krypter en tilfeldig SM4/AES-nøkkel med SM2, deretter dataene med den symmetriske chifferen (SM4-siden / AES-siden).
5. Dekrypter - krever den private nøkkelen
Les chiffertekst som: Orden: Skriv klartekst som:
OpenSSL-kontroll — denne sidens C1C3C2-heks samsvarer med openssl pkeyutl -sm2encrypt -pubin -inkey pub.pem (OpenSSL 3.x med -pkeyopt ec_scheme:c1c3c2, standard), og GmSSL-verktøyene gmssl sm2randkey / sm2encrypt; signaturer samsvarer med openssl dgst -sm3 -sign med samme bruker-ID via -pkeyopt sm2_userid:1234567812345678. En innledende 04-byte før C1 (slik som flere biblioteker produserer) godtas ved dekryptering.
Merknad om samsvar: SM2 er et algoritmevalg drevet av kinesisk kommersiell kryptografisk samsvar og interoperabilitet, med sikkerhet sammenlignbar med 256-bit ECC (NIST P-256). I produksjon bør den kombineres med et ekte system for nøkkelhåndtering eller maskinvarenøkler — en nettleserside er en kalkulator, ikke et hvelv.
Selvtest
Gjenspiller nøkkelavledning-, fast-k-signatur- og krypteringsvektorene produsert av en uavhengig Python-referanseimplementasjon (og kryssjekket mot gmssl), DER-signatur- og DER-chifferrundturene, rundturer for signering/verifisering og kryptering/dekryptering med tilfeldig k, og de negative stiene (manipulert C3, avkortet chiffertekst, offentlig nøkkel utenfor kurven, r = 0).
Hva er SM2?
Kort fortalt: SM2 er det kinesiske nasjonale standard offentlig-nøkkel-kryptosystemet — en elliptisk-kurve-signatur- og krypteringsordning over den faste kurven sm2p256v1, publisert som GB/T 32918-2016 (tidligere GM/T 0003-2012), og spiller i «SM»-pakken den rollen som ECDSA/ECDH (P-256) spiller i NIST-verdenen.
ECC i ett avsnitt (intuisjonen)

All elliptisk-kurve-kryptografi hviler på ett triks: gitt basispunktet G på en kurve over et stort primtallsfelt og multiplumet P = d·G, innebærer det å beregne d fra P å løse det elliptisk-kurve diskrete logaritmeproblemet, og ingen rask algoritme er kjent for det. Den private nøkkelen d er bare et 256-bit tall; den offentlige nøkkelen er punktet d·G. SM2 er ikke ny kurvearitmetikk — det er en bestemt måte å signere (som ECDSA) og kryptere (som en miniatyr-ECIES) på én bestemt kurve, med hashing via SM3 i stedet for SHA.

sm2p256v1 vs NIST P-256
Aspektsm2p256v1NIST P-256 (secp256r1)
Feltstørrelse256-bit primtall256-bit primtall
Kurveformy² = x³ + ax + by² = x³ − 3x + b (a = −3)
Sikkerhetsnivå≈ 128 bit≈ 128 bit
SignaturSM2 (GB/T 32918.2), SM3-basert, bruker-ID bundet inn i ZAECDSA med SHA-256
KrypteringSM2 (GB/T 32918.4), C1C3C2ECIES (ANSI X9.63, ikke NIST-standardisert)
HashSM3 (GB/T 32905)SHA-2-familien
Publisertdesign fra 2010, GM/T 0003-2012, GB/T 32918-2016; i ISO/IEC 14888-31999 (SEC 2 / NIST)
TLS-støtteTLCP (GM/T 386) og TLS 1.3-suiter RFC 8998overalt

Begge kurvene gir samme konkrete sikkerhet; ingen har et praktisk angrep. Valget mellom dem er regulatorisk og knyttet til interoperabilitet, ikke styrke.

Bruker-ID og ZA — det SM2 signerer som ECDSA ikke gjør

Før hashing blander SM2 signatørens identitet inn i digesten: ZA = SM3(ENTL ‖ ID ‖ a ‖ b ‖ xG ‖ yG ‖ xA ‖ yA), der ENTLa er bitlengden til ID-en, de fire midterste feltene låser den nøyaktige kurven, og de to siste er signatørens offentlige nøkkel. Meldingen hashes som SM3(ZA ‖ M). To konsekvenser: en signatur er bundet til den påståtte identiteten (en egenskap), og verifisereren må få oppgitt signatørens ID og bruke den samme (en klassisk interoperabilitetsfelle). Nesten hele økosystemet har landet på den 16-sifrede standarden 1234567812345678 — ikke fra standardteksten, men fra eksemplene i vedlegget til GM/T 0003; OpenSSLs standard stemmer med den, og det gjør denne siden også.

Chiffertekstformater: C1C3C2, C1C2C3 og DER

En SM2-chiffertekst har tre deler: C1 = det midlertidige punktet kG (64 byte, x‖y), C3 = SM3(x2 ‖ M ‖ y2) (32 byte, integritet), C2 = M ⊕ KDF(x2 ‖ y2) (den maskerte meldingen). Teksten fra 2012 (GM/T 0003) satte dem sammen som C1 ‖ C2 ‖ C3; standarden fra 2016 (GB/T 32918.4) omordnet dem til C1 ‖ C3 ‖ C2, og OpenSSL 1.1.1+ fulgte etter. Eldre bank- og offentlige systemer bruker fortsatt den gamle rekkefølgen — derfor har denne siden begge, pluss ASN.1-formen (SEQUENCE av INTEGER x1, INTEGER y1, OCTET STRING C3, OCTET STRING C2) som noen biblioteker produserer. Når dekrypteringen mislykkes med den andre partens verktøy, er byte-rekkefølgen det første å sjekke.

Vanlige feil
  • Gjenbruk eller spare på k. Nonce k i både signering og kryptering må være ny og uforutsigbar for hver operasjon. Én gjentatt k på tvers av to signaturer gir den private nøkkelen til alle som ser begge. Denne siden trekker k fra nettleserens CSPRNG; boksene for fast k finnes bare for å gjenskape kjente vektorer.
  • Ulike bruker-ID-er. Signer med standard-ID og verifiser med en egendefinert (eller omvendt), og hver gyldig signatur feiler. ID-en er en del av de signerte dataene.
  • Å anta C1C3C2 overalt. Systemer fra GM/T 0003-tiden, enkelte smartkort og eldre GmSSL-bygg bruker C1C2C3 som standard; flere verktøy legger også til en ukomprimert punkt-byte 04 foran. Denne siden godtar alle disse ved dekryptering.
  • Kryptering av store datamengder med SM2. Hver chiffertekst bærer 96 byte overhead og koster to punktmultiplikasjoner. Bruk SM2 på en nøkkel, SM4/AES på dataene.
  • Å behandle en offentlig nøkkel med 04-prefiks som 65 råbyte med nøkkel. 04 er en kodingsmarkør: selve nøkkelen er x ‖ y, 128 heksadesimale sifre. Denne siden godtar begge skrivemåtene.
Ofte stilte spørsmål

Er dette kompatibelt med OpenSSL / GmSSL? Ja. C1C3C2-heksutdataene samsvarer med openssl pkeyutl -sm2encrypt for samme offentlige nøkkel, melding og k; DER-signaturer samsvarer med openssl dgst -sm3 -sign-utdata byte for byte (sett bruker-ID med -pkeyopt sm2_userid:...). Kjøringer med tilfeldig k er selvsagt forskjellige — sammenlign ved å dekryptere og verifisere, ikke ved likhet.

Hvorfor finnes det ingen SM2-nøkkelutveksling her? GB/T 32918.3 definerer en interaktiv, autentisert nøkkelutvekslingsprotokoll; den gir ingen mening som en kalkulator på én side. Signering og kryptering dekker de ikke-interaktive bruksområdene.

Finnes SM2 i WebCrypto? Nei — ingen nettleser implementerer det (Chrome leverer det bare bak ikke-standard flagg, om i det hele tatt). Denne siden kjører en JavaScript-implementasjon skrevet fra bunnen av, med standardens egne vedleggsvektorer koblet inn i selvtesten over.

Kan jeg bruke en PEM-nøkkel fra OpenSSL? Eksporter den rå heksen i stedet: openssl ec -in key.pem -text skriver ut den private skalaren og det offentlige punktet. Denne siden tar bare heks-nøkler, med vilje — PEM/SEC1-mekanikken hører hjemme på RSA-siden, der den hører hjemme.

Hva er SM9 så? Et annet dyr: identitetsbasert kryptografi, der en hvilken som helst streng (en e-postadresse) er den offentlige nøkkelen, og en KGC utsteder private nøkler. Se SM9-oversiktssiden.