Beregn HMAC-SHA-256- og HMAC-SHA-512-signaturer med din hemmelige nøkkel — rett i nettleseren din.
HMAC (Hash-based Message Authentication Code, RFC 2104) kombinerer en hemmelig nøkkel med en melding for å produsere en signatur som bare noen med samme nøkkel kan gjenskape. Det er mekanismen bak de fleste webhook-verifiseringer — Stripe, GitHub, Shopify og Slack signerer alle webhook-payloadene sine med HMAC-SHA-256 — samt signerte URL-er, signering av API-forespørsler og integritetskontroll av økttokener. Når en webhook-validering feiler, er det å beregne den forventede signaturen for hånd med dette verktøyet som regel den raskeste veien til å finne avviket.
Beregningen bruker SubtleCrypto, nettleserens innebygde WebCrypto-API: nøkkelen importeres med crypto.subtle.importKey og signaturen produseres med crypto.subtle.sign, så kryptografien er nettleserens egen reviderte implementasjon i stedet for at JavaScript finner den opp på nytt. HMAC er ikke bare hash(nøkkel + melding): den hasher to ganger og blander nøkkelen med to ulike utfyllinger (se formelen nedenfor), noe som lukker length-extension-angrepene som knekker den naive konstruksjonen. Resultatet her gjenskaper testvektorene i RFC 4231 nøyaktig.
Den hemmelige nøkkelen din forlater aldri nettleseren: dette verktøyet gjør ingen nettverksforespørsler, laster ikke opp noe og lagrer ingenting — det kan du bekrefte i nettverksfanen i nettleserens utviklerverktøy. To praktiske råd for produksjonskode: sammenlign alltid signaturer med en sammenligning i konstant tid for å unngå timing-angrep, og sørg for at begge sider signerer nøyaktig de samme bytene — et usynlig avsluttende linjeskift eller en re-serialisert JSON-kropp er den vanligste årsaken til HMAC-avvik.
HMAC(K, m) = H((K xor opad) || H((K xor ipad) || m)), der H er hashfunksjonen og ipad (byte 0x36) og opad (byte 0x5c) gjentas til hashens blokkstørrelse. Den nøstede doble hashingen forhindrer length-extension-angrepene som knekker naive hash(nøkkel + melding)-konstruksjoner.
Den beviser at en melding kom fra noen som har den hemmelige nøkkelen og ikke ble endret underveis. Typiske bruksområder: verifisere webhook-payloader (Stripe, GitHub, Shopify), signere API-forespørsler og beskytte URL-er eller informasjonskapsler mot manipulering.
Nei. Nøkkelen og meldingen behandles 100 % lokalt av nettleserens WebCrypto-API — ingenting overføres, logges eller lagres noe sted.
Nesten alltid en kodingsforskjell: et avsluttende linjeskift, en re-serialisert JSON-kropp, UTF-8 mot en annen koding, eller heksadesimalt resultat sammenlignet med Base64. Signer nøyaktig de samme bytene med samme nøkkel, så vil signaturene stemme.
Begge regnes som sikre. HMAC-SHA-256 er bransjestandarden og det de fleste webhook-leverandører bruker; velg HMAC-SHA-512 når mottakersiden forventer en signatur på 128 tegn.
Nei. HMAC autentiserer en melding, men skjuler den ikke — hvem som helst kan fortsatt lese innholdet. Bruk kryptering for konfidensialitet og HMAC (eller begge, som i autentisert kryptering) for integritet og autentisitet.
Vai.la gjør enhver URL om til en kortlenke med klikkstatistikk, QR Code og din egen biolink.
Vai.la er ikke ansvarlig for hvordan verktøyene brukes, eller for beslutninger tatt på grunnlag av resultatene.