ดี
วิธีการในคำถามนำไปสู่ระบบลายเซ็นที่ตรวจสอบข้อความที่ลงนามสำเร็จเสมอ และมีการรวมกันของโครงร่างการเข้ารหัสแบบอสมมาตรและแฮชที่ระบบลายเซ็นนั้นตรงตาม คุณสมบัติความปลอดภัย EUF-CMA, รวมทั้ง:
- RSAES-สศอ ใกล้เคียงกับที่ปฏิบัติ และแฮชการเข้ารหัสมาตรฐาน เช่น SHA-256 จำเป็นต้องมีการปรับแต่งสองครั้งในส่วน RSA แม้ว่า:
การเลือก $e$ สุ่มและมีขนาดบิตใหญ่ (ครึ่งหนึ่งของขนาดบิตของ $n$ ดูเหมือนตกลง) มากกว่า $e=65537$ ทั่วไป (หรือค่าอื่นที่คาดเดาได้ต่ำกว่า หรือสุ่มแต่ต่ำเกินไปสำหรับความปลอดภัย¹ ของวิธีการของคำถาม)
แสดงคีย์ถอดรหัส $K_{ธันวาคม}$ เช่น $(น,ง)$ แทนที่จะเป็นแบบปกติ $(n,e,d,p,q,d_p,d_q,q_\text{Inv})$ใช้โดยการใช้งานมาตรฐานที่ดูแลประสิทธิภาพ
การเปลี่ยนแปลงทั้งสองจำเป็นต้องเก็บไว้ $e$ ของ $K_{enc}=(n,e)$ ความลับเมื่อเราทำ $K_{dec}=(n,d)$ สาธารณะดังคำถาม
- การเข้ารหัส RSA เช่นเดียวกับใน บทความต้นฉบับ ยกเว้นกับ $n$ ใหญ่พอที่จะต้านทานวิธีการแยกตัวประกอบสมัยใหม่² และแฮชที่ใหญ่กว่าด้านบนมากพอที่จะต้านทาน Desmedt และ Odlyzko โจมตี.
ที่ไม่ดี
วิธีนี้ไม่ปลอดภัยเมื่อใช้กับระบบเข้ารหัสแบบอสมมาตรส่วนใหญ่
สังเกตสิ่งนั้น $K_{ธันวาคม}$ ต้องเปิดเผยต่อสาธารณะเนื่องจากเป็นรหัสยืนยัน และ $K_{enc}$ ต้องเก็บเป็นความลับเนื่องจากเป็นกุญแจสำคัญในการลงนาม ดังนั้นความสัมพันธ์ระหว่างคีย์ทั้งสองจะต้องเป็นเช่นนั้น เราสามารถทำได้ $K_{ธันวาคม}$ สาธารณะในขณะที่รักษาความลับของ $K_{enc}$. RSA เป็นแบบแผนการเข้ารหัสตระกูลเดียวที่ฉันรู้จักดีที่สามารถมีคุณสมบัตินั้นได้ (และตามที่อธิบายไว้ข้างต้น การใช้งานจริงไม่มี)
สำหรับระบบการเข้ารหัสแบบอสมมาตรหลายระบบ ไม่สามารถใช้พร็อพเพอร์ตี้นี้ได้ ตัวอย่างเช่นใน เอลกามาล และเป็นลูกหลานสมัยใหม่ ECIES, $K_{ธันวาคม}$ เป็นจำนวนเต็มที่เข้ารหัสวิธีเข้าถึงองค์ประกอบกลุ่ม $K_{enc}$ โดยใช้กฎหมายกลุ่มภายในกับองค์ประกอบกลุ่มสาธารณะบางอย่าง จึงเปิดเผย $K_{ธันวาคม}$ เผยให้เห็นอย่างหลีกเลี่ยงไม่ได้ $K_{enc}$ทำลายความปลอดภัยของการก่อสร้างคำถาม
โดยทั่วไป การใช้ระบบเข้ารหัสแบบอสมมาตรที่ปลอดภัยและแฮชที่ปลอดภัยไม่ใช่ข้อบ่งชี้ที่ดีว่าระบบลายเซ็นที่ได้รับจากวิธีการของคำถามนั้นปลอดภัย ด้วยเหตุผลหลายประการ
เมื่อเราพิจารณาถึงความปลอดภัยของการใช้งาน มีปัญหาเพิ่มเติม: การใช้งานของ $\texttt{เข้ารหัส}$ ไม่ต้องการการป้องกันการรั่วไหลของช่องด้านข้างของอินพุตคีย์ เนื่องจากโดยปกติแล้วจะเป็นสาธารณะ อย่างไรก็ตาม การป้องกันดังกล่าวจำเป็นสำหรับระบบลายเซ็นของคำถาม
วิธีการนี้มีแนวโน้มที่จะสร้างรูปแบบลายเซ็นที่มีลักษณะต่ำกว่ามาตรฐาน
การเปรียบเทียบลายเซ็น RSA (รวมถึงวิธีการของคำถาม) กับ EdDSA ที่ระดับความปลอดภัยมาตรฐาน:
- ลายเซ็นมีขนาดค่อนข้างใหญ่ (256 ไบต์เทียบกับ 64 ไบต์)
- รหัสสาธารณะมีขนาดใหญ่ (โดยทั่วไปคือ 260 ไบต์เทียบกับ 32 ไบต์)
- การสร้างลายเซ็นช้า (ช้ากว่าหลายสิบเท่า)
- การสร้างคีย์นั้นช้าอย่างเจ็บปวด (ช้ากว่าหลายร้อยเท่า)
และวิธีการนี้ไม่ใช่สิ่งที่ใช้ในการสร้างลายเซ็น RSA แม้แต่ลูกพี่ลูกน้องที่ใกล้ชิด RSA-FDH. ที่ใช้ฟังก์ชันคีย์ส่วนตัวของตำราเรียน RSA $h\mapsto s=h^d$ เพื่อลงนามแฮชแบบกว้าง $h=H(M)$; และฟังก์ชันคีย์สาธารณะของตำราเรียน RSA $s\mapsto h=s^e\bmod n$ ตามด้วยการเปรียบเทียบ $h\overset?=H(M)$ ในการตรวจสอบ ตรงกันข้ามกับวิธีการของคำถาม คีย์สาธารณะ $(น,อี)$ ยังคงเป็นสาธารณะและคีย์ส่วนตัว $(n,e,d,p,q,d_p,d_q,q_\text{Inv})$ ยังคงเป็นความลับ เมื่อเทียบกับที่หรือ RSASSA-PKCS1-v1_5 หรือ RSASSA-PSSวิธีการลงนามของคำถาม:
- สัญญาณช้าลงเกือบสี่เท่าเนื่องจากไม่สามารถใช้ $(n,e,d,p,q,d_p,d_q,q_\text{Inv})$ แบบฟอร์มสำหรับ $K_{ธันวาคม}$
- ตรวจสอบช้ากว่าร้อยถึงพันเท่าเพราะมันใช้ตัวเล็กไม่ได้ $e$.
เธ กับ $n$ ทราบ ถ้าอย่างใดอย่างหนึ่ง $e$ หรือ $d$ เป็นที่รู้จักและน้อยว่า $n^{0.292}$จากนั้นจะพบสิ่งอื่น ๆ ดู โบนห์และเดอร์ฟี. ดังนั้นขีดจำกัดตามธรรมเนียมคือ 256 บิต $e$ (เช่น สร้างขึ้นใน วิธีการสร้างคีย์ของ FIPS 186-4) เป็นสิ่งที่เปิดเผย $d$ อนุญาตให้ค้นหา $e$.
² คำแนะนำดั้งเดิม âนั่น $d$ ควรเลือกจากชุดที่ใหญ่พอที่ cryptanalyst ไม่สามารถค้นหาได้โดยการค้นหาโดยตรงâ แล้วคำนวณ $e$ จาก $d$ ไม่เพียงพอและได้รับอนุญาต ของวีเนอร์ จู่โจมต่อมาปรับปรุงโดย โบนห์และเดอร์ฟี. แต่การรักษา $d$ ความลับและการทำ $e$ สาธารณะเนื่องจากวิธีการของคำถามต้องการการแก้ไขปัญหานั้น