เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
Base64 กับ hex กับ base32: เปรียบเทียบสามวิธีในการเขียนไบต์เป็นข้อความ
· พื้นหลัง
base64 การเข้ารหัส
Hex, base32 และ Base64 แก้ปัญหาเดียวกันโดยมีขนาด ความสามารถในการอ่าน และความปลอดภัยต่างกัน โพสต์นี้เปรียบเทียบความหนาแน่น ความละเอียดอ่อนของตัวพิมพ์เล็กและใหญ่ ความปลอดภัย URL และข้อผิดพลาดของมนุษย์
คีย์ API ที่พิมพ์ผิดเนื่องจาก l, 1, I และ O — ความล้มเหลวในการอ่านอย่างเป็นรูปธรรมที่เลขฐานสิบหกไม่น่าจะมี
วิธีทั่วไปสามวิธีในการแสดงไบต์เป็นข้อความ ได้แก่ hex, base32 และ base64 พวกเขาทั้งหมดแก้ไขปัญหาเดียวกัน (แสดงไบต์ที่กำหนดเองใน ASCII ที่พิมพ์ได้) แต่มีขนาด ความสามารถในการอ่าน และความยืดหยุ่นในการแก้ไขข้อผิดพลาดที่แตกต่างกัน ฐานสิบหกคือ 2 อักขระต่อไบต์ (F3 A2 B1 ...) ดังนั้น 16 bytes จึงกลายเป็น 32 อักขระ Base32 คือ 1.6 อักขระต่อไบต์ (ประมาณ 5 อักขระต่อ 3 bytes) ดังนั้น 16 bytes จึงกลายเป็น 26 อักขระ
Base64 คือ 1.33 อักขระต่อไบต์ (พอดี 4 อักขระต่อ 3 bytes) ดังนั้น 16 bytes จะกลายเป็น 24 อักขระหรือน้อยกว่า หากขนาดไฟล์มีความสำคัญ base64 จะมีขนาดกะทัดรัดที่สุด หากการถอดเสียงของมนุษย์มีความสำคัญ hex และ base32 จะปลอดภัยกว่า ความแตกต่างในการอ่านเป็นสิ่งสำคัญเมื่อมีการพิมพ์ คัดลอก หรือพูดค่า Hex ใช้ 0-9 และ a-f (ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่ในบริบทส่วนใหญ่) ช่องทางการถอดเสียงเปลี่ยนการตัดสินใจ เนื่องจากการนำเสนอที่ปรับให้เหมาะกับเครื่องจักรอาจทำให้ผู้คนรู้สึกอึดอัดได้ Base64 คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่และใช้เครื่องหมายวรรคตอนสองตัว hex ใช้คำศัพท์เชิงภาพที่มีขนาดเล็กกว่า การใช้งานที่นี่จะทดสอบสตริงที่แน่นอน ไม่ใช่อัตราข้อผิดพลาดของมนุษย์ ดังนั้นจึงไม่มีการแนบความน่าจะเป็นที่ประดิษฐ์ขึ้น
ความหนาแน่น: 2×, 1.6× และ 1.33× — จำนวนอักขระที่การเข้ารหัสแต่ละรายการต้องใช้ต่อไบต์ และเพราะเหตุใด
Base32 ใช้ A-Z และ 2-7 หลีกเลี่ยง 0, 1, O และฉัน ซึ่งสับสนได้ง่ายบนกระดาษ Base64 ใช้ A-Z, a-z, 0-9, + และ /, รวมทั้งตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ทำให้คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่และการผสมตัวเลขที่ดูคล้ายกัน (0 กับ O, 1 กับ I กับตัวพิมพ์เล็ก l) คีย์ API ในรูปแบบฐานสิบหกอาจเป็น f3a2b1e4; ไบต์เดียวกันใน base64 อาจเป็น 86KrvE== (มีช่องว่างภายใน) หรือใน base32 6VEV7FI= (มีช่องว่างภายใน)
หากผู้ใช้ต้องพิมพ์ค่าด้วยมือ hex หรือ base32 จะปลอดภัยกว่า base64 อักขระที่สงวนไว้ใน URL มีความสำคัญ Hex และ base32 ปลอดภัยสำหรับ URL ทั้งสองใช้เฉพาะอักขระตัวอักษรและตัวเลข (ฐานสิบหกยังใช้ 0-9, base32 ยังใช้ 2-7) Base64 ใช้เครื่องหมายบวกและเครื่องหมายทับซึ่งสงวนไว้ URL (เครื่องหมายบวกแสดงถึงช่องว่างในข้อมูลที่เข้ารหัสแบบฟอร์ม เครื่องหมายทับคือตัวคั่นเส้นทาง) ความหนาแน่น Base64 ต่อจากบิตที่มีประโยชน์หกบิตต่อสัญลักษณ์เอาต์พุตโดยตรง และตามด้วยบล็อกสี่อักขระ เลขฐานสิบหกประกอบด้วยสี่บิตต่อสัญลักษณ์ ทำให้มีอักขระสองตัวต่อไบต์ Base32 ถูกกล่าวถึงเป็นบริบทการเปรียบเทียบเท่านั้น เนื่องจากพื้นที่เก็บข้อมูลนี้ไม่มีทั้งตัวอักษรหรือตัวเข้ารหัสเพื่อตรวจสอบเอาต์พุต
ความหนาแน่นจากความกว้างบิต — Base64 และเลขคณิตฐานสิบหกที่แน่นอน โดยที่ Base32 ถือเป็นบริบทการเปรียบเทียบ
สตริง base64 ในพารามิเตอร์ URL จะต้องเข้ารหัสแบบเปอร์เซ็นต์ (บวกกลายเป็น %2B เครื่องหมายสแลชกลายเป็น %2F) โดยเพิ่ม 4 อักขระเพิ่มเติมสำหรับแต่ละเหตุการณ์ Base64url (RFC 4648 ส่วน 5) แทนที่เครื่องหมายบวกด้วยเครื่องหมายขีดกลางและเครื่องหมายทับด้วยขีดล่าง ทำให้ URL ปลอดภัยโดยไม่ต้องเข้ารหัสเปอร์เซ็นต์ API ส่วนใหญ่ที่ใช้ base64 ใน URL จริงๆ แล้วใช้ base64url แต่ความแตกต่างมักไม่ชัดเจนในเอกสารประกอบ
ความลับ TOTP (รหัสที่ใช้โดยแอปตรวจสอบความถูกต้อง) โดยทั่วไปจะกระจายเป็น base32 หน้าจอการลงทะเบียน TOTP จะแสดงข้อมูลลับ base32 เนื่องจากพิมพ์และถอดเสียงได้ง่ายกว่าไบต์เดียวกันใน base64 หรือฐานสิบหก SHA การแยกแฮชมักจะแสดงในรูปแบบฐานสิบหกเนื่องจากเป็นรูปแบบดั้งเดิม และเนื่องจากฐานสิบหกไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ ทำให้การพิมพ์ผิดมีโอกาสน้อยลง ความละเอียดอ่อนของตัวพิมพ์มีความสำคัญเมื่อมีคนอ่านออกเสียงค่าหรือพิมพ์ซ้ำ เนื่องจากการเปลี่ยนตัวพิมพ์ของตัวอักษรหนึ่งตัวจะเปลี่ยนดัชนีของค่านั้น ToolAcre รักษาขนาดตัวพิมพ์ให้ตรงกันและจะถอดรหัสผลลัพธ์ไบต์ที่แตกต่างกันโดยไม่รู้ว่ามนุษย์ทำข้อผิดพลาดในการถอดความ การเป็นตัวแทนนั้นไม่มีผลรวมตรวจสอบ
อักขระที่สงวนไว้และความปลอดภัย URL — โดยที่ + และ / กัด และวิธีที่ base32 และ hex หลีกเลี่ยงปัญหา
JWT ใช้ base64url การตรวจสอบไฟล์อาจเป็นฐานสิบหกหรือฐาน 64 ทั้งสองเป็นเรื่องธรรมดา ทางเลือกคือแบบแผนทางประวัติศาสตร์ ไม่ใช่ความจำเป็นทางเทคนิค การฟื้นตัวจากข้อผิดพลาดถือเป็นข้อแตกต่างที่ละเอียดอ่อนแต่สำคัญ Base32 หลีกเลี่ยงตัวเลข 0, 1, 8 และ 9 (ซึ่งมีลักษณะเหมือนตัวอักษร) ช่วยลดข้อผิดพลาดในการถอดความ Base64 มีตัวเลขทั้งหมด ทำให้ 1 ไม่ชัดเจน (เป็นตัวอักษร I ตัวพิมพ์เล็ก l หรือตัวเลข 1?)
Hex มีแนวโน้มที่จะเกิดข้อผิดพลาดมากขึ้น: 0 ดูเหมือน O, l ดูเหมือน 1 เช็คซัมที่ต้องพิมพ์หรืออ่านจากงานพิมพ์จะปลอดภัยกว่าใน base32 คีย์ API ที่วางโดยตรงจากคอมพิวเตอร์จะปลอดภัยในทุกรูปแบบ ความสามารถในการอ่านจะมีความสำคัญเฉพาะเมื่อเกี่ยวข้องกับดวงตาของมนุษย์เท่านั้น ไบต์เหมือนกัน แต่การเข้ารหัสแตกต่างกัน: ลำดับ 16 ไบต์ [0xf3, 0xa2, 0xb1, ...] กลายเป็น f3a2b1... เครื่องหมายบวกและเครื่องหมายทับของ Base64 มาตรฐานจำเป็นต้องมีการจัดการช่องสัญญาณที่รับรู้ URL-เซฟโหมดจะแทนที่ด้วยยัติภังค์และขีดล่าง เลขฐานสิบหกหลีกเลี่ยงการใช้ตัวคั่นเหล่านั้นโดยใช้ตัวเลขและตัวอักษรเพียงอย่างเดียว แบบแผน Base32 แตกต่างกันไป ดังนั้นบทความนี้จึงหลีกเลี่ยงคุณสมบัติด้านความปลอดภัยที่มีแนวโน้มว่าพื้นที่เก็บข้อมูลไม่ได้ใช้หรือทดสอบ
ตัวอย่างการทำงาน: 16 bytes เหมือนกันในการเข้ารหัสทั้งสามแบบ - การเปรียบเทียบความยาวและการตรวจสอบด้วยภาพ
ในฐานสิบหก, 6VEV7FI=... ใน base32 และ 86KrvE== ใน base64 สตริงเหล่านี้ไม่สามารถใช้แทนกันได้ แอปพลิเคชันที่ได้รับ f3a2b1... คาดว่าจะมีเลขฐานสิบหก และจะพยายามแยกวิเคราะห์เป็นเลขฐานสิบหก การรับ 86KrvE== จะล้มเหลวหากแอปพลิเคชันคาดหวังเลขฐานสิบหก รูปแบบการเข้ารหัสเป็นส่วนหนึ่งของสัญญาข้อมูล: ผู้ส่งและผู้รับต้องตกลงกันว่าจะใช้การเข้ารหัสใด การแพ็ดดิ้งเป็นอีกความแตกต่างหนึ่ง
เลขฐานสิบหกไม่ใช้ช่องว่างภายใน (4 bytes จะเป็นอักขระฐานสิบหก 8 เสมอ ไม่มีข้อยกเว้น) ทั้ง Base32 และ base64 ใช้การเติมเท่ากับเพื่อจัดเอาต์พุตให้มีหลายอักขระ (8 สำหรับ base32, 4 สำหรับ base64) จำเป็นต้องมีช่องว่างภายในทางคณิตศาสตร์ ช่วยให้มั่นใจได้ว่าทุกอินพุต n ไบต์จะสร้างจำนวนอักขระตามที่กำหนด กฎการเติมจะแตกต่างกันไป: บางแอปพลิเคชันจำเป็นต้องมีการเติม ส่วนบางแอปพลิเคชันอนุญาตให้ละเว้นได้ การเปรียบเทียบการทำงานใช้ลำดับไบต์คงที่และคำนวณ Base64 และเลขฐานสิบหกแบบกลไก ความยาว Base32 สามารถพูดคุยได้จากการจัดกลุ่มห้าบิต แต่ค่าข้อความ Base32 ที่แน่นอนจะถูกละไว้ เนื่องจากไม่มีการใช้งานที่ได้รับการตรวจสอบที่สร้างขึ้น การคำนวณความยาวและการตรวจสอบผลลัพธ์จะแยกกัน
โดยที่แต่ละรายการเป็นแบบธรรมดา - แฮชในรูปแบบฐานสิบหก, TOTP ความลับใน base32, JWT และข้อมูล: URI ใน Base64
เมื่อวางค่า base32 หรือ base64 โดยไม่มีช่องว่างภายใน ตัวถอดรหัสอาจยอมรับหรือปฏิเสธค่าดังกล่าว ขึ้นอยู่กับการใช้งาน คีย์การเข้ารหัสและโทเค็นแสดงความแตกต่างในการเข้ารหัส
คีย์ HMAC คือ 32 bytes ซึ่งกลายเป็นอักขระ 64 อักขระฐานสิบหก, 52 อักขระ base32 (พร้อมช่องว่างภายใน) หรือ 44 อักขระฐาน 64 (พร้อมช่องว่างภายใน) เมื่อแจกจ่ายคีย์ ควรมีการบันทึกการเข้ารหัสไว้ หากเอกสารประกอบระบุว่าคีย์คือ 44 อักขระ base64 แต่คุณได้รับอักขระ 52 ตัว แสดงว่ามีบางอย่างผิดปกติ อนุสัญญาสามารถชี้แนะผู้อ่านได้ แต่ไม่ได้พิสูจน์ความเหมาะสม โดยทั่วไปแฮชไดเจสต์จะแสดงเป็นเลขฐานสิบหก ในขณะที่เซ็กเมนต์ JWT ใช้ Base64url ตัวเลือกที่ถูกต้องยังคงขึ้นอยู่กับกฎของช่องสัญญาณ ไม่ว่าผู้คนจะคัดลอกค่าหรือไม่ และโปรโตคอลอื่นได้แก้ไขการเป็นตัวแทนแล้วหรือไม่
สิ่งนี้ไม่ครอบคลุมถึงการเข้ารหัส base58, base85 และเช็คซัม
การเข้ารหัส base64 ที่สั้นกว่าทำให้ง่ายขึ้นเล็กน้อยในการปรับโทเค็นเข้ากับระบบที่มีการจำกัดจำนวนอักขระ (เช่น รหัส QR หรือ URL) ตัวเลือกการเข้ารหัสสำหรับค่าจะถูกกำหนดโดยระบบนิเวศใดก็ตามที่มาจาก Web API มักใช้ base64url เอกสารการเข้ารหัสมักใช้เลขฐานสิบหก แอพ Authenticator ใช้ base32 เมื่อสร้างระบบ ให้เลือกการเข้ารหัสหนึ่งรายการ จัดทำเอกสารให้ชัดเจน และยึดติดกับมัน
การเข้ารหัสแบบผสม (พูดว่า base64 หรือ base32) ทำให้เกิดความสับสน เมื่อทำการดีบัก ขั้นตอนแรกคือการระบุว่าค่าใดที่ใช้การเข้ารหัส เครื่องมือเข้ารหัสและถอดรหัส Base64 สามารถช่วยได้โดยการพยายามถอดรหัสหลายวิธีและดูว่าอันใดที่สร้างเอาต์พุตที่สมเหตุสมผล ไม่มีการเข้ารหัสใดจะดีไปกว่านี้ในระดับสากล Base64 มีขนาดกะทัดรัดที่สุดสำหรับการจัดเก็บแบบดิบ Hex เป็นที่คุ้นเคยมากที่สุดสำหรับนักเข้ารหัสลับ และส่วนใหญ่มนุษย์สามารถอ่านได้สำหรับลำดับเล็กๆ การเข้ารหัส Base58, Base85 และเช็คซัมมีข้อดีข้อเสียที่แตกต่างกัน และไม่มีอยู่ในแผง Base64 ของ ToolAcre ตัวอักษร กฎความกำกวม และผลรวมตรวจสอบควรได้รับการประเมินด้วยแหล่งที่มาและการนำไปใช้งานโดยเฉพาะ แทนที่จะอนุมานจากพฤติกรรมที่ทดสอบของเครื่องมือนี้
ประเด็นสำคัญ: เลือกการเข้ารหัสสำหรับช่องและเครื่องอ่าน — วิธีที่ตัวเข้ารหัสและตัวถอดรหัส Base64 ครอบคลุมเคส Base64 ในเบราว์เซอร์ ควบคู่ไปกับเครื่องคำนวณแฮช SHA ในผลิตภัณฑ์เดียวกันอย่างไร
Base32 มีความยืดหยุ่นสูงสุดต่อข้อผิดพลาดในการถอดเสียง ตัวเลือกขึ้นอยู่กับบริบท: มูลค่าอยู่ที่ใด แบ่งปันอย่างไร และระบบใดที่จะใช้ค่านั้น
การทำความเข้าใจข้อดีข้อเสียช่วยให้คุณเลือกได้อย่างชาญฉลาดเมื่อออกแบบ API หรือระบบ เครื่องมือเข้ารหัสและถอดรหัส Base64 สาธิตการเข้ารหัส base64 การใช้มันร่วมกับเครื่องมือ hex หรือ base32 ช่วยให้คุณเห็นไบต์เดียวกันในทั้งสามรูปแบบ และเข้าใจความแตกต่างของขนาดและความสามารถในการอ่าน สำหรับกรณี Base64 ให้เข้ารหัสตัวอย่าง จดจำนวน UTF-8 ไบต์และอักขระเอาต์พุตที่แน่นอน และทดสอบมาตรฐานกับเครื่องหมายวรรคตอนที่ปลอดภัย URL สำหรับงานสรุปข้อมูล ให้ใช้แผง SHA แยกต่างหาก การทำให้การดำเนินการเหล่านั้นแตกต่างออกไปจะป้องกันไม่ให้ตัวเลือกการเข้ารหัสถูกเข้าใจผิดว่าเป็นการแฮชหรือการปกป้องความสมบูรณ์