ToolDeck

HMAC Generator

Generate HMAC signatures with SHA-256, SHA-384, or SHA-512

Algorithm

Message

ประมวลผลในเครื่อง · ปลอดภัยในการวางข้อมูลลับ

Secret Key

ประมวลผลในเครื่อง · ปลอดภัยในการวางข้อมูลลับ

HMAC Signature

HMAC signature will appear here…

HMAC คืออะไร?

HMAC (Hash-based Message Authentication Code) คือโครงสร้างเข้ารหัสที่กำหนดใน RFC 2104 ซึ่งรวมฟังก์ชันแฮชเข้ากับกุญแจลับเพื่อสร้างแท็กยืนยันตัวตนขนาดคงที่ ต่างจากแฮชธรรมดาที่ใครก็คำนวณได้ HMAC สามารถสร้างและตรวจสอบได้เฉพาะผู้ที่ถือกุญแจลับร่วมกันเท่านั้น HMAC คือกลไกมาตรฐานสำหรับตรวจสอบทั้งความสมบูรณ์และความถูกต้องของข้อความ — ยืนยันว่าข้อมูลไม่ถูกแก้ไข และมาจากผู้ส่งที่น่าเชื่อถือ

อัลกอริทึม HMAC ทำงานร่วมกับฟังก์ชันแฮชแบบวนซ้ำใดก็ได้: SHA-256, SHA-384, SHA-512 และแม้แต่ฟังก์ชันเดิมอย่าง SHA-1 หรือ MD5 โครงสร้างที่ได้เรียกตามแฮชพื้นฐาน เช่น HMAC-SHA256, HMAC-SHA384 หรือ HMAC-SHA512 เนื่องจากความปลอดภัยของ HMAC ขึ้นอยู่กับความต้านทาน collision ของฟังก์ชันแฮชและคุณสมบัติ pseudorandom บางประการ อัลกอริทึมในตระกูล SHA-2 จึงเป็นตัวเลือกที่แนะนำสำหรับระบบใหม่ HMAC-SHA256 เป็นตัวแปรที่ใช้งานกว้างขวางที่สุด ครอบคลุม AWS Signature V4, Stripe webhooks, GitHub webhook secrets, Slack request signing และ JSON Web Tokens (HS256)

การออกแบบของ HMAC มอบคุณสมบัติสำคัญที่แฮชธรรมดาไม่มี: ความต้านทานต่อ length-extension attack ด้วย SHA-256 เพียงอย่างเดียว ผู้โจมตีที่รู้ H(message) สามารถคำนวณ H(message || attacker_data) ได้โดยไม่รู้ข้อความต้นฉบับ โครงสร้าง double-hashing ของ HMAC (inner hash และ outer hash ด้วย padded key ต่างกัน) ป้องกันการโจมตีนี้ได้อย่างสมบูรณ์ นี่คือเหตุผลที่ scheme ลายเซ็น API ใช้ HMAC แทนการต่อกุญแจลับกับข้อความแล้วแฮชผลลัพธ์

RFC 2104 — HMAC: Keyed-Hashing for Message Authentication →

ทำไมต้องใช้เครื่องสร้าง HMAC ออนไลน์?

การคำนวณลายเซ็น HMAC โดยปกติต้องเขียนโค้ดหรือใช้เครื่องมือ CLI เครื่องสร้าง HMAC บนเบราว์เซอร์นี้ช่วยให้คุณสร้างลายเซ็น HMAC-SHA256, HMAC-SHA384 และ HMAC-SHA512 ได้ทันทีโดยไม่ต้องติดตั้งซอฟต์แวร์หรือเปิด terminal

คำนวณ HMAC ได้ทันที
ป้อนข้อความและกุญแจลับ เลือกอัลกอริทึมแฮช แล้วรับลายเซ็น HMAC ทันที Web Crypto API จัดการการคำนวณโดยตรงในเบราว์เซอร์ของคุณ
🔒
ประมวลผลโดยเน้นความเป็นส่วนตัว
ข้อความและกุญแจลับของคุณไม่เคยออกจากอุปกรณ์ การคำนวณ HMAC ทั้งหมดทำงานภายในเครื่องผ่าน Web Crypto API — ไม่มีการส่งคำขอไปยังเซิร์ฟเวอร์ ไม่มีการบันทึก ไม่มีการเก็บข้อมูล
📋
รองรับหลายอัลกอริทึม
สลับระหว่าง HMAC-SHA256, HMAC-SHA384 และ HMAC-SHA512 ด้วยคลิกเดียว เปรียบเทียบผลลัพธ์ข้ามอัลกอริทึมเพื่อตรวจสอบว่า backend ของคุณสร้างผลลัพธ์ตรงกัน
🔍
ไม่ต้องสมัครสมาชิกหรือติดตั้ง
ใช้งานได้ในเบราว์เซอร์สมัยใหม่ทุกตัว — Chrome, Firefox, Safari, Edge ไม่ต้องสมัคร ไม่ต้องติดตั้ง extension ไม่ต้องตั้งค่า CLI เปิดหน้าและเริ่มสร้างลายเซ็น HMAC ได้เลย

กรณีการใช้งานเครื่องสร้าง HMAC

นักพัฒนา Frontend — ตรวจสอบลายเซ็น Webhook
Stripe, GitHub และ Shopify เซ็นชื่อ webhook payload ด้วย HMAC-SHA256 ใช้เครื่องมือนี้คำนวณลายเซ็นที่คาดหวังจาก payload และ secret แล้วเปรียบเทียบกับลายเซ็นใน HTTP header ระหว่างการพัฒนา
วิศวกร Backend — เซ็นชื่อคำขอ API
AWS Signature V4 ต้องการ HMAC-SHA256 ในหลายขั้นตอนของกระบวนการเซ็นชื่อ สร้างค่า HMAC อ้างอิงระหว่างการพัฒนาเพื่อแก้ไขปัญหาความไม่ตรงกันของลายเซ็นและตรวจสอบขั้นตอนการคำนวณกลาง
DevOps — ตรวจสอบการหมุนเวียน Secret
เมื่อหมุนเวียน webhook secret หรือกุญแจเซ็นชื่อ API ให้คำนวณลายเซ็น HMAC ด้วยทั้งกุญแจเก่าและกุญแจใหม่ เพื่อยืนยันว่าแอปพลิเคชันของคุณจัดการการเปลี่ยนผ่านได้ถูกต้องก่อนกุญแจเก่าหมดอายุ
วิศวกร QA — สร้าง Test Vector สำหรับลายเซ็น
สร้าง HMAC test vector ด้วย input และกุญแจที่ทราบ เพื่อสร้าง regression test สำหรับ authentication middleware ของคุณ ตรวจสอบว่าการใช้งานของคุณจัดการข้อความว่าง input Unicode และกุญแจยาวได้ถูกต้อง
วิศวกรข้อมูล — ยืนยันตัวตนข้อความใน Pipeline
แนบลายเซ็น HMAC กับข้อความใน event-driven pipeline (Kafka, SQS) เพื่อตรวจสอบว่าข้อความไม่ถูกแก้ไขระหว่างการส่งระหว่างบริการ
นักศึกษา — งานวิชาการเข้ารหัส
ทดลองกับ HMAC เพื่อทำความเข้าใจว่าการเปลี่ยนอักขระเพียงตัวเดียวในข้อความหรือกุญแจให้ผลลายเซ็นที่แตกต่างกันอย่างสิ้นเชิง เปรียบเทียบผลลัพธ์ HMAC กับผลลัพธ์ SHA-256 ธรรมดาเพื่อสังเกตความแตกต่างที่กุญแจลับสร้างขึ้น

HMAC กับแฮชธรรมดา กับการเข้ารหัส

HMAC แฮชธรรมดา และการเข้ารหัสมีวัตถุประสงค์ต่างกัน HMAC มอบการยืนยันตัวตนของข้อความ — หลักฐานว่าข้อความถูกสร้างโดยผู้ที่มีกุญแจลับและไม่ถูกแก้ไข แฮชธรรมดามอบความสมบูรณ์แต่ไม่มีการยืนยันตัวตน การเข้ารหัสมอบการรักษาความลับ ตารางด้านล่างชี้แจงความแตกต่าง

คุณสมบัติHMACPlain HashEncryption
PurposeMessage authentication + integrityData integrity only (no key)Confidentiality + integrity
Requires secret keyYesNoYes
Verifiable byParties who share the secretAnyoneRecipient with key
ReversibleNo — digest onlyNo — digest onlyYes — decryption recovers data
Output sizeDepends on hash (e.g. 256 bits)Depends on hashVariable (ciphertext)
StandardRFC 2104FIPS 180-4NIST SP 800-38A (AES)
Use case exampleWebhook signature verificationFile checksum verificationEncrypting data at rest

การเปรียบเทียบอัลกอริทึม HMAC

HMAC ใช้ได้กับฟังก์ชันแฮชใดก็ได้ แต่การเลือกอัลกอริทึมพื้นฐานกำหนดขนาดผลลัพธ์ ระดับความปลอดภัย และความเข้ากันได้กับเบราว์เซอร์ HMAC-SHA256 เป็นตัวเลือกที่พบบ่อยที่สุดสำหรับระบบใหม่ ตารางด้านล่างเปรียบเทียบตัวแปรที่คุณน่าจะพบ

อัลกอริทึมขนาด Digestความยาว Hexเว็บ คริปโตเหมาะสำหรับ
HMAC-SHA256256 bits64 hex charsYesAPI signing, webhooks, JWT (HS256)
HMAC-SHA384384 bits96 hex charsYesTLS 1.3 PRF, CNSA compliance
HMAC-SHA512512 bits128 hex charsYesHigh-security signatures, HKDF
HMAC-SHA1160 bits40 hex charsYesLegacy OAuth 1.0, TOTP (RFC 6238)
HMAC-MD5128 bits32 hex charsNoLegacy only — not recommended

HMAC ทำงานภายในอย่างไร?

HMAC ใช้ฟังก์ชันแฮชพื้นฐานสองครั้งด้วย pad ที่ได้จากกุญแจสองแบบที่ต่างกัน โครงสร้างนี้กำหนดใน RFC 2104 และพิสูจน์แล้วว่าเป็น PRF (pseudorandom function) ภายใต้สมมติฐานเข้ารหัสมาตรฐาน กุญแจถูก pad หรือแฮชก่อนเพื่อให้ตรงกับขนาดบล็อกของฟังก์ชันแฮช (64 ไบต์สำหรับ SHA-256, 128 ไบต์สำหรับ SHA-512)

HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))
where K' = key padded to block size, ipad = 0x36, opad = 0x5C

อัลกอริทึม XOR กุญแจที่ pad แล้วกับค่าคงที่ inner pad (ipad, 0x36 ซ้ำ) ต่อกับข้อความ แล้วแฮชผลลัพธ์ จากนั้น XOR กุญแจที่ pad แล้วกับค่าคงที่ outer pad (opad, 0x5C ซ้ำ) ต่อกับผลลัพธ์ inner hash แล้วแฮชอีกครั้ง โครงสร้าง double-hashing นี้คือสิ่งที่ป้องกัน length-extension attack และรับประกันว่าผลลัพธ์ HMAC ไม่สามารถคำนวณได้โดยไม่รู้กุญแจลับ

ตัวอย่างโค้ด HMAC

HMAC ได้รับการรองรับโดยตรงในทุกภาษาและ runtime หลัก Web Crypto API มี HMAC-SHA256, HMAC-SHA384 และ HMAC-SHA512 ในเบราว์เซอร์โดยไม่ต้องใช้ไลบรารี ตัวอย่างด้านล่างแสดงรูปแบบการใช้งานจริง รวมถึงการตรวจสอบ webhook และการเปรียบเทียบแบบ constant-time

JavaScript (Web Crypto API)
async function hmacSHA256(message, secret) {
  const enc = new TextEncoder()
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(message))
  return Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0')).join('')
}

await hmacSHA256('hello world', 'my-secret-key')
// → "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"

// Node.js (built-in crypto module)
const crypto = require('crypto')
crypto.createHmac('sha256', 'my-secret-key')
  .update('hello world').digest('hex')
// → "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"
Python
import hmac
import hashlib

# HMAC-SHA256
sig = hmac.new(
    b'my-secret-key',
    b'hello world',
    hashlib.sha256
).hexdigest()
print(sig)
# → "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"

# Verify a webhook signature (constant-time comparison)
expected = "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"
received = hmac.new(b'my-secret-key', b'hello world', hashlib.sha256).hexdigest()
if hmac.compare_digest(expected, received):
    print("Signature valid")

# HMAC-SHA512
hmac.new(b'key', b'data', hashlib.sha512).hexdigest()
Go
package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "fmt"
)

func main() {
    mac := hmac.New(sha256.New, []byte("my-secret-key"))
    mac.Write([]byte("hello world"))
    sig := mac.Sum(nil)
    fmt.Printf("%x\n", sig)
    // → 90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad

    // Verify: use hmac.Equal for constant-time comparison
    expected := mac.Sum(nil)
    fmt.Println(hmac.Equal(sig, expected)) // true
}
CLI (OpenSSL)
# HMAC-SHA256
echo -n "hello world" | openssl dgst -sha256 -hmac "my-secret-key"
# → SHA2-256(stdin)= 90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad

# HMAC-SHA512
echo -n "hello world" | openssl dgst -sha512 -hmac "my-secret-key"

# Verify a file signature
openssl dgst -sha256 -hmac "my-secret-key" release.tar.gz

# HMAC with hex key (e.g. from a webhook secret)
echo -n "payload" | openssl dgst -sha256 -hmac "$(echo -n '736563726574' | xxd -r -p)"

คำถามที่พบบ่อย

HMAC กับแฮชธรรมดาต่างกันอย่างไร?
แฮชธรรมดา (SHA-256, MD5) รับเฉพาะข้อความเป็น input และสร้าง digest ที่ใครก็คำนวณได้ HMAC รับทั้งข้อความและกุญแจลับ สร้างลายเซ็นที่เฉพาะผู้ที่มีกุญแจเท่านั้นที่สร้างหรือตรวจสอบได้ ซึ่งหมายความว่า HMAC มอบการยืนยันตัวตน (หลักฐานตัวตนผู้ส่ง) นอกเหนือจากการตรวจสอบความสมบูรณ์ แฮชธรรมดาเพียงพิสูจน์ว่าข้อมูลไม่เปลี่ยนแปลง ไม่ใช่ว่าใครสร้าง
HMAC-SHA256 ปลอดภัยหรือไม่?
ใช่ HMAC-SHA256 ถือว่าปลอดภัย ณ ปี 2026 ความปลอดภัยอาศัยคุณสมบัติ pseudorandom ของ SHA-256 และโครงสร้าง HMAC เอง (RFC 2104) ไม่มีการโจมตีเชิงปฏิบัติต่อ HMAC-SHA256 ที่ถูกพิสูจน์แล้ว แม้แต่ HMAC-MD5 และ HMAC-SHA1 ยังคงปลอดภัยในทางปฏิบัติ เพราะความปลอดภัยของ HMAC ไม่ต้องการความต้านทาน collision เต็มรูปแบบของแฮชพื้นฐาน อย่างไรก็ตาม แนะนำให้ใช้ตัวแปร SHA-2 สำหรับระบบใหม่
ทำไม webhook ถึงใช้ HMAC แทนการเข้ารหัส payload?
Webhook payload มักมีข้อมูลที่ผู้รับคาดหวังอยู่แล้ว เช่น รายละเอียดคำสั่งซื้อ การแจ้งเตือนเหตุการณ์ การอัปเดตสถานะ เป้าหมายไม่ใช่การซ่อนข้อมูล (การรักษาความลับ) แต่เพื่อพิสูจน์ว่ามาจากผู้ส่งที่ถูกต้องและไม่ถูกแก้ไขระหว่างทาง (ความถูกต้องและความสมบูรณ์) HMAC ทำสิ่งนี้ด้วย overhead ต่ำ: ผู้ส่งคำนวณ HMAC ของ payload ด้วย shared secret และรวมไว้ใน HTTP header ผู้รับคำนวณ HMAC ใหม่แล้วเปรียบเทียบ การเข้ารหัสจะเพิ่มความซับซ้อนและภาระการจัดการกุญแจโดยไม่จำเป็น
ควรเปรียบเทียบลายเซ็น HMAC อย่างปลอดภัยอย่างไร?
ต้องใช้ฟังก์ชันเปรียบเทียบแบบ constant-time เสมอ ใน Python ใช้ hmac.compare_digest() ใน Node.js ใช้ crypto.timingSafeEqual() ใน Go ใช้ hmac.Equal() โอเปอเรเตอร์เปรียบเทียบสตริงมาตรฐาน (== หรือ ===) อาจรั่วข้อมูล timing: ผู้โจมตีสามารถวัดเวลาที่ใช้ในการเปรียบเทียบเพื่อระบุว่ากี่ไบต์ของลายเซ็นปลอมตรงกับลายเซ็นที่ถูกต้อง แล้ว brute-force ไบต์ที่เหลือทีละตัว
HMAC สามารถย้อนกลับเพื่อกู้คืนกุญแจลับได้หรือไม่?
ไม่ได้ HMAC อาศัยฟังก์ชันแฮชทางเดียว ดังนั้นไม่มีทางคณิตศาสตร์ที่จะดึงกุญแจออกจากผลลัพธ์ HMAC ผู้โจมตีต้อง brute-force พื้นที่กุญแจซึ่งเป็นไปไม่ได้สำหรับกุญแจ 128 บิตหรือยาวกว่า อย่างไรก็ตาม กุญแจที่อ่อนแอหรือสั้น (เช่น รหัสผ่านง่าย ๆ) อาจเสี่ยงต่อ dictionary attack ดังนั้นควรใช้กุญแจที่สุ่มเข้ารหัสขนาดอย่างน้อย 256 บิตสำหรับ HMAC-SHA256 เสมอ
จะเกิดอะไรขึ้นหากกุญแจ HMAC ยาวกว่าขนาดบล็อกของแฮช?
หากกุญแจลับยาวกว่าขนาดบล็อกของฟังก์ชันแฮช (64 ไบต์สำหรับ SHA-256, 128 ไบต์สำหรับ SHA-512) อัลกอริทึม HMAC จะแฮชกุญแจก่อนด้วยฟังก์ชันแฮชพื้นฐานเพื่อลดให้เหลือความยาวผลลัพธ์ของแฮช แล้วใช้แฮชนั้นเป็นกุญแจจริง ซึ่งหมายความว่ากุญแจยาวมากไม่ได้มอบความปลอดภัยเพิ่มเติมเกินขนาดผลลัพธ์ของแฮช สำหรับ HMAC-SHA256 กุญแจที่ยาวกว่า 64 ไบต์จะถูกแฮชลงเหลือ 32 ไบต์และไม่มอบความปลอดภัยดีกว่ากุญแจ 64 ไบต์ กุญแจที่ไม่เกิน 64 ไบต์ใช้งานตามความยาวเต็ม
ควรใช้ HMAC-SHA512 แทน HMAC-SHA256 เมื่อใด?
ใช้ HMAC-SHA512 เมื่อโปรโตคอลกำหนด (บาง key derivation function เช่น HKDF-SHA512, การสร้างกุญแจ Ed25519) เมื่อต้องการลายเซ็นที่กว้างขึ้นเพื่อการป้องกันเชิงลึก หรือเมื่อทำงานบนฮาร์ดแวร์ 64 บิตที่ SHA-512 เร็วกว่า SHA-256 จริง ๆ สำหรับเว็บแอปพลิเคชัน การเซ็นชื่อ API และการตรวจสอบ webhook ส่วนใหญ่ HMAC-SHA256 มอบความปลอดภัยเพียงพอและเป็นตัวเลือกที่พบบ่อยกว่าในระบบนิเวศ

คู่มือภาษา