Score:0

ใช้แฮชของข้อมูลเพื่อพิสูจน์ความสมบูรณ์และป้องกันการชนกัน

ธง us

แทนที่จะจัดเก็บข้อมูลผู้ใช้เมื่อโต้ตอบกับแอป ฉันกำลังจัดเก็บข้อมูล SHA3-256เนื่องจากการจัดเก็บข้อมูลในสภาพแวดล้อมเฉพาะนี้มีจำกัดมาก

ข้อมูลสามารถเป็นได้หลายตัวแปร เช่น a, b, และ, c แต่แทนที่จะบันทึกทีละรายการ ฉันจะบันทึกแฮชของการต่อข้อมูล: SHA3(a,b,c)

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

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

เพื่ออธิบายรายละเอียดข้างต้น เหตุผลที่ฉันคิดว่าสิ่งนี้อาจทำให้ผู้ใช้ค้นหาการชนกันได้ง่ายเนื่องจาก a, b และ c เป็นประเภทที่แตกต่างกันและมีค่าต่ำสุดและสูงสุด ตัวอย่างเช่น ถ้า c สามารถมีค่าระหว่าง 10 ถึง 1,000 เท่านั้น ผู้ใช้สามารถลองใช้ค่าที่เป็นไปได้ทั้งหมดของ C เพื่อทดสอบการชนกันของโชคโดยไม่ต้องใช้ความพยายามมากนัก นี่เป็นข้อกังวลที่สมเหตุสมผลหรือไม่?

โปรดทราบว่าใครเป็นผู้ส่งข้อมูลนั้นไม่สำคัญ เพียงแต่ว่าข้อมูลที่รวบรวมมานั้นเหมือนกับข้อมูลที่รวบรวมไว้ก่อนหน้านี้ทุกประการ

SEJPM avatar
us flag
การโจมตีแบบคลาสสิกเกี่ยวกับสิ่งนี้คือการส่ง a เป็น 0 ไบต์และ b เป็นสองศูนย์เป็นไบต์และการแลกเปลี่ยนความสัมพันธ์ของชิ้นส่วนข้อมูลเหล่านี้ในภายหลัง ซึ่งจะส่งผลให้เกิดแฮชที่เหมือนกันสำหรับกรณีการต่อข้อมูล แต่จะแตกต่างกันสำหรับกรณีที่แฮชล่วงหน้าทีละรายการ
Jaime avatar
us flag
ขอบคุณสำหรับความคิดเห็น พารามิเตอร์เป็นประเภทที่มีความยาวที่กำหนดไว้ เช่น "a" couls เป็น 32Bytes, "b" 64 bytes และ "c" 128 bytes ในกรณีนี้การโจมตีใช้ไม่ได้ใช่ไหม. โดยทั่วไป ถ้าความยาวของตัวแปรคงที่ สมมติว่าเป็น 32 ไบต์ การโจมตีที่คุณอธิบายไม่สามารถทำได้ใช่ไหม
SEJPM avatar
us flag
ได้ หากคุณสามารถ _รับประกัน_ ความยาวของอินพุตอย่างน้อยทั้งหมดยกเว้นหนึ่งอินพุตที่จะได้รับการแก้ไขเสมอ คุณมักจะได้รับคุณสมบัติความปลอดภัยเต็มรูปแบบของโครงสร้างประเภทความสมบูรณ์
Score:1
ธง in

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

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

Score:0
ธง de

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

การตั้งค่าของคุณไม่ปลอดภัยจากการโจมตีซ้ำอย่างแน่นอน คุณจะต้องปฏิบัติตามเทคนิคการสุ่มหรือเกลือ

โพสต์คำตอบ

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