เกลือที่นี่เป็นทางเลือก แต่การใช้เกลือจะเพิ่ม "ความแข็งแรง" จะมีประโยชน์ก็ต่อเมื่อ MasterKey อ่อนแอหรือไม่?
หากมาสเตอร์คีย์ไม่สุ่มอย่างสม่ำเสมอ แสดงว่า ขั้นตอนการสกัด
แยกการสุ่มแบบสม่ำเสมอจากเอนโทรปีปัจจุบันของ Input Key Material (IKM) (รหัสผ่านหรือคีย์ของคุณ หรือ ..) เกลือช่วยเพิ่มความแข็งแกร่งให้กับ HKDF และสนับสนุนการสกัดโดยไม่ขึ้นกับแหล่งที่มา เพื่อให้ IKM ที่แตกต่างกันสองรายการลงเอยด้วยผลลัพธ์การสกัดที่แตกต่างกันสองรายการ หนึ่งอาจได้รับประโยชน์จากการสกัดที่ไม่ขึ้นกับแหล่งที่มาแม้ว่าพวกเขาจะมีรหัสสุ่มที่สม่ำเสมอและมีความแข็งแรงเพียงพอ
หาก MasterKey ของฉันแข็งแกร่ง "เพียงพอ" ฉันยังต้องการเกลืออีกหรือไม่ ถ้าไม่ อะไรจะแข็งแกร่งเพียงพอ? สตริงฐานสิบหกแบบสุ่มยาว 32 อักขระเพียงพอหรือไม่
แข็งแกร่งไม่ใช่เมตริก หากคุณมีบิตสุ่มที่เหมือนกัน คุณไม่จำเป็นต้องใช้ ขั้นตอนการสกัด
ของ HKDF ขนาดของบิตขึ้นอยู่กับตำแหน่งที่คุณจะใช้ 128 บิตสำหรับ AES-128, 256 บิต AES-256 เป็นต้น
ถ้าฉันยังควรใช้เกลืออยู่ เป็นไปได้ไหมที่ B, C และ D ทั้งหมดจะใช้เกลือเดียวกันร่วมกัน หรือต้องไม่ซ้ำกัน (ใน RFC ระบุว่าเกลือสามารถนำกลับมาใช้ใหม่ได้ แต่ไม่แน่ใจว่าหมายถึงอะไรทั้งหมด)
จริงๆ แล้ว เมื่อคุณได้รับ PseudoRandom Key (PRK) จากขั้นตอนการ Extract แล้ว เพื่อให้ได้มาซึ่งคีย์ คุณต้องเปลี่ยนแท็กข้อมูลเท่านั้น.
การใช้เกลือซ้ำหมายความว่าไม่มีการสกัดที่ไม่ขึ้นกับแหล่งที่มา คุณกำลังขยาย PRK เดียวกันบน ขยายขั้นตอน
. คุณอาจต้องการใช้ PRK ที่แตกต่างกันสำหรับผู้ใช้ที่แตกต่างกัน
เกลือทั่วโลกโอเคไหม?
ขั้นตอนขยายใช้ HMAC กับคีย์ PRK
HMAC-Hash(PRK, T(0) | ข้อมูล | 0x01)
HMAC เป็น PRF และคุณใช้ global salt แล้วแก้ไข PRF ปัญหาเดียวที่ฉันเห็นคือการชนกันของผลผลิตในระยะยาว ในขณะที่เราสามารถสร้างและจัดเก็บเกลือได้อย่างง่ายดาย และได้รับตระกูล PRF แทนที่จะเป็นตระกูลเดียว แล้วทำไมจะไม่ใช้เกลือที่แตกต่างกันต่อผู้ใช้?
มีสองส่วนที่ยอดเยี่ยมใน rfc5869
3.1. เกลือหรือไม่มีเกลือ
ถึงกระนั้นก็ตามค่าเกลือที่มีคุณภาพน้อยกว่า (สั้นกว่าใน
ขนาดหรือมีเอนโทรปีจำกัด) ก็ยังอาจมีนัยสำคัญได้
การมีส่วนร่วมในการรักษาความปลอดภัยของวัสดุคีย์เอาต์พุต นักออกแบบ
การใช้งานจึงได้รับการสนับสนุนให้ระบุค่าเกลือ
HKDF หากแอปพลิเคชันสามารถรับค่าดังกล่าวได้
แอปพลิเคชั่นบางตัวอาจมีค่าเกลือลับสำหรับใช้งาน ในกรณีเช่นนี้ HKDF ให้การรับประกันความปลอดภัยที่แข็งแกร่งยิ่งขึ้น
3.2 อินพุต 'ข้อมูล' ไปยัง HKDF
...วัตถุประสงค์หลักคือการผูกเนื้อหาหลักที่ได้รับเข้ากับข้อมูลเฉพาะแอปพลิเคชันและบริบท ตัวอย่างเช่น 'ข้อมูล' อาจมีหมายเลขโปรโตคอล ตัวระบุอัลกอริทึม ข้อมูลระบุตัวตนของผู้ใช้ ฯลฯ โดยเฉพาะอย่างยิ่ง อาจป้องกันการได้มาของข้อมูลคีย์เดียวกันสำหรับบริบทที่แตกต่างกัน (เมื่อใช้วัสดุคีย์อินพุตเดียวกัน (IKM) ในลักษณะดังกล่าว ต่างบริบท)
อันที่จริง นี่ไม่ใช่วิธีที่ถูกต้องในการสร้างและแจกจ่ายคีย์ คุณควรพิจารณาโซลูชันการเข้ารหัสคีย์สาธารณะ เช่น RSA-KEM หรือ ECHE ซึ่งต้องส่งผ่านผลลัพธ์ของทั้งสองอย่างจาก KDF ก่อนนำไปใช้ในการเข้ารหัส