---
title: "ฟังก์ชันแฮชเชิงเข้ารหัส"
description: "คู่มือฟังก์ชันแฮชเชิงเข้ารหัสที่เน้นการตรวจสอบ ครอบคลุมคุณสมบัติด้านความปลอดภัย การเข้ารหัสไบต์ SHA-2, SHA-3, Keccak การใช้งานในบล็อกเชน และความเสี่ยงในการนำไปใช้"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ฟังก์ชันแฮชเชิงเข้ารหัส

> เนื้อหานี้มีไว้เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำด้านการลงทุนหรือการนำวิทยาการเข้ารหัสไปใช้ ไดเจสต์ที่ตรงกันเพียงอย่างเดียวไม่ได้พิสูจน์ความแท้จริง ความเป็นเจ้าของ การอนุญาต ความสมบูรณ์เด็ดขาด หรือความพร้อมใช้งานของข้อมูล

<a id="answer"></a>

## คำตอบโดยตรง

ฟังก์ชันแฮชเชิงเข้ารหัสจะแปลงข้อความที่แสดงในรูปไบต์เป็นไดเจสต์ที่มีความยาวเอาต์พุตกำหนดไว้อย่างแน่นอนและให้ผลเหมือนเดิมเสมอ สำหรับแฮช `n` บิตที่มีความยาวคงที่ ความสัมพันธ์พื้นฐานคือ:

`h = H(m), where h is in {0,1}^n`

ไบต์และอัลกอริทึมเดียวกันจะให้ไดเจสต์เดียวกัน การเปลี่ยนอินพุตเพียงหนึ่งบิตควรทำให้บิตเอาต์พุตจำนวนมากเปลี่ยนไปอย่างคาดเดาไม่ได้ แต่ปรากฏการณ์ avalanche นี้ไม่ใช่นิยามของความปลอดภัย เป้าหมายหลักด้านความปลอดภัย ได้แก่ **ความต้านทานการย้อนหาข้อมูลต้นฉบับ** (เมื่อทราบไดเจสต์แล้ว การหาอินพุตที่สร้างไดเจสต์นั้นต้องทำไม่ได้ในทางปฏิบัติ), **ความต้านทานการหาข้อมูลต้นฉบับชุดที่สอง** (เมื่อทราบอินพุตหนึ่งชุดแล้ว การหาอินพุตอีกชุดที่ให้ไดเจสต์เดียวกันต้องทำไม่ได้ในทางปฏิบัติ) และ **ความต้านทานการชนกัน** (การหาอินพุตต่างกันสองชุดใด ๆ ที่ให้ไดเจสต์เดียวกันต้องทำไม่ได้ในทางปฏิบัติ)

การแฮชไม่ใช่การเข้ารหัสลับ เพราะไม่มีคีย์สำหรับถอดรหัสและไม่มีการรับรองว่าจะกู้คืนอินพุตได้ เนื่องจากข้อความที่เป็นไปได้จำนวนอนันต์ถูกแมปลงในพื้นที่เอาต์พุตที่มีขอบเขต การชนกันจึงต้องมีอยู่ ความปลอดภัยหมายถึงการหาการชนกันที่นำไปใช้ประโยชน์ได้ต้องไม่คุ้มค่าในเชิงการคำนวณสำหรับอัลกอริทึมและความยาวเอาต์พุตที่เลือก

ไดเจสต์เพียงอย่างเดียวยังไม่ยืนยันความแท้จริง การคำนวณแฮชของไฟล์ใหม่จะตรวจพบความไม่ตรงกันได้ก็ต่อเมื่อไดเจสต์ที่คาดไว้และอัลกอริทึมมาจากช่องทางที่เชื่อถือได้ โปรโตคอลสร้างหลักประกันที่แข็งแรงขึ้นด้วยการใช้แฮชร่วมกับลายเซ็น รหัสยืนยันความถูกต้องของข้อความ โครงสร้างข้อมูลที่ผ่านการยืนยัน กฎฉันทามติ หรือ proof-of-work

<a id="mechanism"></a>

## วิธีการทำงาน

1. **กำหนดไบต์ให้แน่นอน.** การเข้ารหัสข้อความ ตัวพิมพ์ใหญ่และเล็ก ช่องว่าง ลำดับฟิลด์ การแทนจำนวนเต็ม คำนำหน้าความยาว และการทำ serialization ล้วนส่งผลต่อ `m` โปรโตคอลต้องกำหนดการเข้ารหัสแบบมาตรฐานและผูกแฮชไว้กับอัลกอริทึม เวอร์ชัน เครือข่าย และวัตถุประสงค์ที่ชัดเจน
2. **ใช้โครงสร้างที่ระบุ.** SHA-256 จะประมวลผลข้อความที่มีความยาวจำกัดล่วงหน้า แบ่งเป็นบล็อก และอัปเดตสถานะภายในซ้ำ ๆ ส่วน SHA3-256 ใช้โครงสร้าง sponge ที่สร้างจาก KECCAK ทั้งสองให้ไดเจสต์ 256 บิต แต่เป็นคนละฟังก์ชันและใช้เอาต์พุตแทนกันไม่ได้
3. **ตีความความปลอดภัยตามคุณสมบัติที่ต้องการ.** สำหรับแฮช `n` บิตในอุดมคติ การค้นหาข้อมูลต้นฉบับแบบทั่วไปใช้การประเมินประมาณ `2^n` ครั้ง ขณะที่การค้นหาการชนกันแบบทั่วไปใช้ประมาณ `2^(n/2)` ครั้งเนื่องจาก birthday effect ความยาวเอาต์พุตเพียงอย่างเดียวไม่เพียงพอ หากอัลกอริทึมถูกเจาะ ไดเจสต์ถูกตัดทอน หรือโปรโตคอลรอบข้างมีข้อบกพร่อง
4. **สร้างโปรโตคอลรอบไดเจสต์.** ระบบลายเซ็นดิจิทัลสามารถลงนามไดเจสต์ของข้อความได้ HMAC เพิ่มคีย์ลับเพื่อยืนยันความถูกต้องของข้อความ ต้นไม้ Merkle ผูกมัดใบจำนวนมากไว้ด้วย root เดียว และ proof-of-work แฮชส่วนหัวบล็อกที่เป็นตัวเลือกซ้ำ ๆ จนกว่าไดเจสต์จะตรงตามเป้าหมาย โครงสร้างเหล่านี้ให้หลักประกันที่ต่างกัน
5. **ใช้ฟังก์ชันที่ตรงกับเชนนั้น.** ส่วนหัวบล็อกและโหนด Merkle ของ Bitcoin ใช้ SHA-256 สองรอบตามลำดับไบต์ที่กำหนด การประมวลผลของ Ethereum ใช้ Keccak-256 จากแบบ KECCAK ก่อนการกำหนดมาตรฐาน ไม่ใช่ SHA3-256 ตามมาตรฐาน ดังนั้นป้ายกำกับอย่าง "แฮช 256 บิต" จึงไม่เพียงพอสำหรับการตรวจสอบ
6. **ตรวจสอบบริบทก่อนตีความความหมาย.** ตรวจสอบแหล่งที่มาของไดเจสต์ที่คาดไว้ ตัวระบุอัลกอริทึม การเข้ารหัสไบต์ โดเมนหรือเชน จุดอ้างอิงบล็อกและสถานะ สถานะการยืนยัน และการตัดทอนใด ๆ การคำนวณที่ถูกต้องกับบริบทที่ผิดยังคงเป็นการตรวจสอบที่ล้มเหลว

<a id="example"></a>

## ตัวอย่างพร้อมคำอธิบาย

- **การเปลี่ยนอินพุตเพียงเล็กน้อย.** SHA-256 ของไบต์ UTF-8 ห้าไบต์สำหรับ `hello` คือ `2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824` เมื่อเปลี่ยนไบต์แรกเป็นตัวพิมพ์ใหญ่ `H` จะได้ `185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969` ไดเจสต์ที่ต่างกันไม่เผยว่าไบต์ใดถูกเปลี่ยน
- **ระดับความปลอดภัยไม่เท่ากับความยาวไดเจสต์ในทุกแบบจำลองการโจมตี.** แฮช 256 บิตในอุดมคติให้ภาระงานในการย้อนหาข้อมูลต้นฉบับประมาณ `2^256` แต่ภาระงานในการหาการชนกันอยู่ที่ `2^128` ความแตกต่างนี้สำคัญเมื่อโปรโตคอลพึ่งพาความต้านทานการชนกัน เช่น กระบวนการลายเซ็นดิจิทัลที่มักเป็นเช่นนั้น
- **หลักฐาน Merkle ยืนยันการรวมข้อมูลโดยอิงกับ root หนึ่งค่า.** ผู้ตรวจสอบจะแฮชใบที่เข้ารหัสแล้วกับ sibling แต่ละค่าที่ได้รับตามลำดับที่ระบุ จนสร้าง root ที่ผูกมัดไว้ขึ้นมาใหม่ การตรงกันไม่ได้พิสูจน์ว่า root มีความสมบูรณ์เด็ดขาด ข้อมูลในใบเป็นความจริง หรือข้อมูลที่ละไว้พร้อมใช้งาน
- **Proof-of-work เพิ่มกฎของค่าเป้าหมาย.** Bitcoin จะยอมรับส่วนหัวที่เป็นตัวเลือกก็ต่อเมื่อค่า SHA-256 สองรอบของมัน เมื่อตีความตามกฎฉันทามติแล้ว น้อยกว่าหรือเท่ากับเป้าหมายที่เข้ารหัสไว้ ไดเจสต์ไม่ได้ต้านทานการชนกันมากขึ้นเพียงเพราะนักขุดใช้กำลังประมวลผลมากขึ้น

<a id="risks"></a>

## ความเสี่ยง

- ใช้อัลกอริทึมที่เลิกใช้แล้วหรือไม่เหมาะสม โดยเฉพาะการพึ่งพา SHA-1 ในกรณีที่ต้องการความต้านทานการชนกัน
- ถือว่า SHA3-256, Keccak-256, SHA-256, SHA-256 สองรอบ และรูปแบบที่ตัดทอนต่างกันสามารถใช้แทนกันได้
- แฮชข้อความที่แสดงแทนไบต์มาตรฐาน หรือมองข้ามการทำ Unicode normalization ช่องว่าง endianness ลำดับฟิลด์ และการเข้ารหัสความยาว
- ดาวน์โหลดไฟล์และไดเจสต์ที่คาดไว้จากแหล่งเดียวกันที่ถูกเจาะ ซึ่งไม่ทำให้เกิดการตรวจสอบความสมบูรณ์ที่เป็นอิสระ
- ใช้แฮชอเนกประสงค์ที่รวดเร็วโดยตรงเพื่อเก็บรหัสผ่าน แทนระบบแฮชรหัสผ่านที่ใส่ salt ออกแบบมาเฉพาะ และมี work factor ที่เหมาะสม
- ใช้ `H(secret || message)` เป็นรหัสยืนยันความถูกต้องที่ทำขึ้นเอง โครงสร้างแฮชแบบวนซ้ำบางชนิดเปิดให้โจมตีด้วยการต่อความยาวได้ ขณะที่ HMAC ออกแบบมาสำหรับการยืนยันด้วยคีย์
- ตัดทอนไดเจสต์โดยไม่คำนวณระดับความปลอดภัยต่อการชนกันและการย้อนหาข้อมูลต้นฉบับที่เหลืออยู่ตามขนาดและแบบจำลองภัยคุกคามของโปรโตคอล
- ใช้การเข้ารหัสเดียวกันข้ามโปรโตคอลโดยไม่มีการแยกโดเมน ทำให้ไดเจสต์ที่ใช้ได้ในบริบทหนึ่งถูกตีความในอีกบริบทหนึ่ง
- สันนิษฐานว่าแฮชธุรกรรมพิสูจน์การยืนยัน ความสมบูรณ์เด็ดขาด การดำเนินการสำเร็จ ความเป็นเจ้าของ หรือการปลอดจากการจัดระเบียบเชนใหม่
- สันนิษฐานว่าแฮชเนื้อหาทำให้เรียกคืนข้อมูลที่อ้างถึงได้ ข้อผูกมัดอาจยังถูกต้องแม้สำเนาที่มีอยู่ทั้งหมดจะหายไป
- เปรียบเทียบสตริงใน explorer โดยไม่ตรวจสอบลำดับไบต์ กฎคำนำหน้า serialization หรือว่าอินเทอร์เฟซแสดงตัวระบุภายในต่างออกไปหรือไม่
- นำ primitive ทางวิทยาการเข้ารหัสไปใช้โดยไม่มีเวกเตอร์ทดสอบมาตรฐาน ไลบรารีที่ได้รับการดูแล การตรวจสอบโดยอิสระ และกระบวนการอัปเกรด

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

- **แฮชคือข้อมูลที่เข้ารหัสลับ.** การเข้ารหัสลับย้อนกลับได้ด้วยคีย์ที่ถูกต้อง ส่วนแฮชเชิงเข้ารหัสคือไดเจสต์ทางเดียวที่ไม่มีการถอดรหัส
- **อินพุตต่างกันไม่มีทางให้ไดเจสต์เดียวกัน.** การชนกันต้องมีอยู่สำหรับเอาต์พุตความยาวคงที่ การออกแบบที่ปลอดภัยทำให้การค้นหาและใช้ประโยชน์จากมันทำไม่ได้ในทางปฏิบัติ
- **ไดเจสต์ 256 บิตให้ความปลอดภัย 256 บิตเสมอ.** ความต้านทานการชนกันแบบทั่วไปของแฮช 256 บิตในอุดมคติอยู่ที่ประมาณ 128 บิต และการเลือกออกแบบโปรโตคอลอาจลดลงไปอีก
- **แฮชที่ตรงกันพิสูจน์ว่าใครสร้างข้อความ.** แฮชเปล่าไม่มีข้อมูลลับและไม่ยืนยันผู้ส่ง หากที่มามีความสำคัญ ให้ใช้ลายเซ็นหรือ MAC ที่เหมาะสม
- **Keccak-256 และ SHA3-256 เป็นสองชื่อของฟังก์ชันเดียวกัน.** ทั้งคู่ใช้การออกแบบที่สัมพันธ์กันอย่างใกล้ชิด แต่พารามิเตอร์มาตรฐานต่างกันและให้ไดเจสต์ต่างกัน
- **แฮชธุรกรรมบนเชนพิสูจน์การชำระเสร็จสิ้น.** แฮชระบุข้อมูลธุรกรรมที่เข้ารหัสไว้ ส่วนการรวมเข้าเชน สถานะการดำเนินการ การยืนยัน และความสมบูรณ์เด็ดขาดเป็นข้อเท็จจริงคนละเรื่อง

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [บล็อกเชน](/th/crypto/blockchain/)
- [ไตรเลมมาของบล็อกเชน](/th/crypto/blockchain-trilemma/)
- [ต้นไม้ Merkle](/th/crypto/merkle-tree/)
- [Proof of work](/th/crypto/proof-of-work/)

<a id="sources"></a>

## แหล่งข้อมูล

- [ฟังก์ชันแฮช](https://csrc.nist.gov/projects/hash-functions) - NIST (เข้าถึงเมื่อ: 2026-08-20)
- [มาตรฐานแฮชที่ปลอดภัย (SHS)](https://doi.org/10.6028/NIST.FIPS.180-4) - NIST (เข้าถึงเมื่อ: 2026-08-20)
- [มาตรฐาน SHA-3: ฟังก์ชันแฮชและฟังก์ชันเอาต์พุตขยายได้ที่อิงการเรียงสับเปลี่ยน](https://doi.org/10.6028/NIST.FIPS.202) - NIST (เข้าถึงเมื่อ: 2026-08-20)
- [เอกสารอ้างอิงสำหรับนักพัฒนา Bitcoin: บล็อกเชน](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin.org (เข้าถึงเมื่อ: 2026-08-20)
- [Yellow Paper ของ Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) - Ethereum (เข้าถึงเมื่อ: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/cryptographic-hash/index.mdx