ToolDeck

เครื่องสร้าง HMAC

สร้างลายเซ็น HMAC ด้วย SHA-256 SHA-384 หรือ SHA-512

อัลกอริทึม

ข้อความ

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

กุญแจลับ

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

ลายเซ็น HMAC

ลายเซ็น HMAC จะแสดงที่นี่…

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 แทนการต่อกุญแจลับกับข้อความแล้วแฮชผลลัพธ์

ทำไมต้องใช้เครื่องสร้าง 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 มอบความปลอดภัยเพียงพอและเป็นตัวเลือกที่พบบ่อยกว่าในระบบนิเวศ