Score:0

อัลกอริทึมการเข้ารหัสแบบสมมาตรขึ้นอยู่กับการคูณ

ธง tf
Tom

ฉันสงสัยเกี่ยวกับย่อหน้านี้มาระยะหนึ่งแล้ว:

การคูณเป็นฟังก์ชันการผสมที่ยอดเยี่ยม หากคุณคิดว่าการคูณมีลักษณะอย่างไรในแง่ของ AND และ XOR จะเห็นได้ชัดว่าการคูณแบบ 64 บิตซับซ้อนเพียงใด จำนวนทรานซิสเตอร์ที่ต้องใช้ในฮาร์ดแวร์ห้ามไม่ให้มีการใช้การคูณในอัลกอริธึมการเข้ารหัสส่วนใหญ่ แต่สำหรับ PRNG ที่ไม่ใช่การเข้ารหัสซึ่งจำเป็นต้องทำงานบน CPU วัตถุประสงค์ทั่วไปเท่านั้น การคูณจะมีประโยชน์มากเนื่องจากมีการใช้งานฮาร์ดแวร์อยู่แล้ว

https://tom-kaitchuck.medium.com/designing-a-new-prng-1c4ffd27124d

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

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

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

phantomcraft avatar
pf flag
เว้นแต่ว่า CPU จะมีตัวคูณฮาร์ดแวร์เป็นจำนวนเต็ม ก็ไม่น่ามีปัญหา ปัญหาเริ่มต้นเมื่อใช้งานในสภาพแวดล้อมที่มีขนาดเล็กมาก เช่น สมาร์ทการ์ด เมื่อโปรเซสเซอร์ขนาดเล็กทำงานขั้นพื้นฐานมากเท่านั้นตามที่คุณอ้างถึง
Score:5
ธง my

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

ส่วนหนึ่งของปัญหาดูเหมือนจะเป็นคำจำกัดความของคำว่า 'lightweight' และแพลตฟอร์มที่ตั้งใจให้เป็นเป้าหมาย ซีพียูบนสมาร์ทโฟนมีความสามารถจริง ฉันจะไม่อธิบายลักษณะแพลตฟอร์มเหล่านั้น (หรือคอมพิวเตอร์แล็ปท็อป) ว่าจำเป็นต้อง 'เบา' โดยทั่วไป crypto ที่มีน้ำหนักเบาได้รับการออกแบบโดยคำนึงถึงไมโครคอนโทรลเลอร์ โดยทั่วไปแล้วไมโครคอนโทรลเลอร์เหล่านั้นไม่มีคำสั่งการคูณแบบ 64x64 บิตในตัว

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

ปัญหาอื่น ๆ ดูเหมือนจะเป็นการคูณแบบแยกส่วนไม่ได้ยอดเยี่ยมอย่างที่คุณคาดหวัง สำหรับการสนทนานี้ ฉันจะจำกัดการสนทนาของฉันไว้ที่การคูณโมดูโล a ยกกำลัง 2 (หลายโมดูโล a ไพรม์ไม่มีปัญหาเหล่านี้ พวกเขามีปัญหาเกี่ยวกับช่วงที่ไม่เป็นยกกำลัง 2)

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

  • การคูณแบบแยกส่วนมีความแตกต่างอย่างมาก ความแข็งแกร่งขึ้นอยู่กับตัวตน $(-x)*y = -(x*y)$ (และการทำงานของโมดูลัสไม่ได้ทำให้สิ่งนี้แตกสลาย)

ประเด็นทั้งสองนี้สามารถออกแบบได้อย่างเหมาะสม อย่างไรก็ตาม ข้อเท็จจริงที่คุณต้องทำเช่นนั้นทำให้ความน่าสนใจลดลง นอกจากนี้ยังทำให้เกิดคำถาม: ทำไมไม่ใช้การคูณ $GF(2^k)$ แทน? หากเรากำลังดำเนินการแบบ shift/add การปรับใช้การคูณแบบ Galois แบบ double/xor นั้นไม่ได้มีราคาแพงกว่ามากนัก และเป็นการหลีกเลี่ยงสองประเด็นข้างต้น...

Tom avatar
tf flag
Tom
แน่นอนว่าการคูณ mod 2^n มีปัญหาใหญ่ในการผสมบิต (โดยเฉพาะค่าต่ำ) นั่นเป็นเหตุผลที่เรารวมมันเข้ากับ xor และหมุน แต่เท่าที่ฉันทราบ นอกจากนี้ ยังมีประเด็นที่ใหญ่กว่าในประเภทนี้ ฉันไม่แน่ใจ แต่อาจเป็นส่วนต่างที่แข็งแกร่งกว่า
Tom avatar
tf flag
Tom
การคูณ GF(2^k) จะเร็วเท่ากับการคูณเลข 64 บิต mod 2^64 ได้หรือไม่ ฉันคิดว่ามันต้องเป็น GF(2^64) ถึงจะได้จำนวนบิตเท่ากัน
poncho avatar
my flag
@Tom: เห็นได้ชัดว่าคำตอบดังกล่าวจะขึ้นอยู่กับฮาร์ดแวร์ สำหรับ CPU ขนาดใหญ่ ฉันเชื่อว่ามีการดำเนินการแบบ 'carryless multiply'; การแก้ไขที่จำเป็นนั้นไม่ฟรี ดังนั้นมันจะช้ากว่าการคูณ 64x64 ตรงๆ แต่ก็ไม่เลว สำหรับ CPU ขนาดเล็ก (ไม่มีการคูณ) ค่า xor $GF(2^{64})$ สองเท่า/เงื่อนไขแบบคงที่ตามเวลาควรใกล้เคียงกับการคูณแบบกะ/เงื่อนไขแบบอะนาล็อกเพิ่ม 64x64...
Tom avatar
tf flag
Tom
ฉันสร้างเครื่องกำเนิด LCG แบบ 32 บิตและเครื่องกำเนิด LCG ใน GF(2^32) และการคูณใน GF(2^32) ประสิทธิภาพแย่ลงเล็กน้อยใน PractRand ดูเหมือนว่าจะมีปัญหากับบิตต่ำด้วย จะไม่มีความแตกต่างอื่น ๆ อีกเหรอ? ฉันไม่แน่ใจ. ดูเหมือนว่าการคูณใน GF(2) จะไม่ทำให้บิตผสมดีขึ้น หรือบางทีข้อดีหลักคือหาตัวคูณผกผันได้ยากขึ้น?
poncho avatar
my flag
@Tom: ข้อดีของการคูณ GF คือ: ถ้าไม่ทราบ $a \ne 0$ และ $b$ และกระจายอย่างสม่ำเสมอ ดังนั้น $a \times b$ ก็จะถูกกระจายอย่างสม่ำเสมอเช่นกัน สิ่งนี้ไม่เป็นความจริงสำหรับการคูณโมดูโลยกกำลัง 2 ถ้า $a = 2$ และ $a \times b$ จะเป็นเลขคู่เสมอ
Score:4
ธง ye

รหัสบล็อก ความคิด จากปี 1991 ใช้ modular multiplication mod $2^{16}+1$ สำหรับการแพร่ (โดยที่ 0 ถูกแมปกับ $2^{16}$).

เนื่องจากตัวหารศูนย์ไม่ดีจากมุมมองของการเข้ารหัส โมดูลัสควรเป็นจำนวนเฉพาะและอยู่ในรูปแบบ $2^b+1$ เนื่องจากคนชอบทำงานกับบิต (และไม่ใช้ 0) ดังนั้น $b=2, 4, 8, 16$ ($b=1$ จะเป็นเส้นตรง)

หากคุณออกแบบรหัสโดยใช้การคูณแบบแยกส่วน คุณจะพบกับปัญหา (อย่างน้อย) 2 ประการ:

  • คุณสมบัติการเข้ารหัสของการคูณแบบโมดูลาร์ยังไม่เข้าใจดี ทำให้คุณยากที่จะแสดงว่ารหัสของคุณดี
  • สำหรับอุปกรณ์ขนาดเล็กต้องพิจารณาการโจมตีช่องทางด้านข้าง แต่เป็นการยากที่จะป้องกันการคูณแบบโมดูลาร์เหล่านี้จากสิ่งเหล่านั้น (โดยเฉพาะอย่างยิ่งกับ DPA; แต่การโจมตีด้วยจังหวะเวลาแล้วอาจเป็นปัญหา หากการคูณไม่ใช่เวลาคงที่)
poncho avatar
my flag
ฉันจะยืนยันว่าเข้าใจคุณสมบัติการเข้ารหัสของการคูณแบบแยกส่วน นอกจากนี้ สำหรับ DPA การคูณแบบโมดูลาร์นั้นเป็นมิตรกับเกณฑ์ โดยยึดตามเอกลักษณ์ $(A+B)*(C+D) = (A*C + B*D) + (A*D + B*C )$ (ซึ่งขยายไปในทางที่ชัดเจนสำหรับ 3+-way thresholding)
Tom avatar
tf flag
Tom
การโจมตีช่องทางด้านข้างและการโจมตีตามเวลาเป็นปัญหาที่ต้องพิจารณาจริงๆ ฉันลืมไปแล้ว อย่างไรก็ตาม การบวกก็เสี่ยงต่อปัญหาดังกล่าวเหมือนกันไม่ใช่หรือ หรืออาจไม่ใช่เพราะเราแปลงเป็น shift และ xors ซึ่งเป็นเวลาคงที่ได้ง่ายๆ
poncho avatar
my flag
@Tom: ปัญหาหลักเกี่ยวกับเวลาและการคูณอยู่บนแพลตฟอร์มระดับล่าง บนแพลตฟอร์มเหล่านั้น คำสั่งการคูณอาจไม่ใช่เวลาคงที่ (เช่น หยุดเมื่อตัวถูกดำเนินการตัวใดตัวหนึ่งหมด '1' บิต) ตอนนี้ คุณสามารถใช้การคูณเวลาคงที่บนแพลตฟอร์มเหล่านั้นได้ อย่างไรก็ตามผู้ดำเนินการ crypto-naïve อาจไม่ใช่ ในทางตรงกันข้าม CPU มักจะใช้การเพิ่มในเวลาคงที่เสมอ...
Tom avatar
tf flag
Tom
อีกหนึ่งคำถาม ในการรับการคูณแบบอะนาล็อก 64 บิต (mod 2^64) ควรใช้ GF อะไร ฉันต้องการคูณตัวเลข 64 บิตและได้ผลลัพธ์ 64 บิต ฉันต้องใช้ GF(2^64) ใช่ไหม มีตัวอย่างของ GF(2^8) ทุกที่ AES ยังทำงานบน GF(2^8) แต่ทำงานเป็นไบต์ถ้ามีคนต้องการแทนที่การคูณแบบ 64 บิต เขาต้องใช้ GF(2^64) ใช่ไหม หรืออาจจะเป็นอย่างอื่นเช่นใน AES GF(2^8) แต่เป็นไบต์? ดังนั้นกฎของเลขคณิตดังกล่าวจะแตกต่างกันเล็กน้อย กว่าใน GF(2^64) ถ้าฉันเข้าใจถูกต้อง
ye flag
@poncho: สูตรที่คุณให้ไว้สำหรับการติดตั้งเกณฑ์ซ่อนปัญหาการใช้งานสองประการ: การเพิ่มคือ mod $2^{16}+1$ ดังนั้นการแบ่งปันเพิ่มเติมจึงไม่พอดีกับ 16 บิต และคุณต้องการการลดแบบแยกส่วนที่นำไปใช้งานได้ง่าย แต่คุณต้องพิจารณาว่าผู้โจมตีสามารถมองเห็นค่าที่ไม่ได้ลดลง (ผ่าน DPA) แต่ปัญหาที่แท้จริงสำหรับการปรับใช้ DPA-secure จะปรากฏขึ้นเมื่อคุณผสมการคูณแบบแยกส่วนกับการดำเนินการอื่นๆ เช่น xor หรือการเพิ่ม mod $2^{16}$ เนื่องจากคุณต้องสลับไปมาระหว่างการดำเนินการกำบังต่างๆ ซึ่งไม่ใช่เรื่องเล็กน้อย (และใช้เวลานาน).
ye flag
@Tom: คุณรู้ไหมว่าการคูณในช่องที่มีองค์ประกอบ $2^{64}$ นั้นค่อนข้างแตกต่างจากการคูณ mod $2^{64}$?
Tom avatar
tf flag
Tom
@garfunkel ใช่ มันแตกต่าง ฉันรู้ ฉันศึกษาหัวข้อนี้และเขียนโปรแกรมการคูณของตัวเอง และแม้กระทั่งฟังก์ชันการคูณ GF(2^128) ตามคำสั่งโหมด GCM และ pclmulqdq
ye flag
@Tom: (จากการเขียนของคุณ ฉันคิดว่าคุณรู้ และถามเพื่อความแน่ใจ) ข้อแตกต่างเพิ่มเติมสองข้อระหว่างการใช้ mod การคูณ $2^{16}+1$ (ใช้องค์ประกอบฟิลด์ทั้งหมดยกเว้น 0) และการคูณในฟิลด์ด้วย $2^{16}$ (ใช้องค์ประกอบฟิลด์ทั้งหมดรวมถึง 0) คือค่าหลังมีจุดคงที่ที่ 0 เสมอ และ - ที่สำคัญกว่านั้นมาก - ค่าหลังเป็นเส้นตรงเหนือ F2 ("xor") ดังนั้นจึงขาดสิ่งสำคัญไปอย่างหนึ่ง คุณสมบัติของ S-Box เข้ารหัส เช่นเดียวกับใน AES คุณอาจต้องใช้การผกผันเหนือฟิลด์ด้วยองค์ประกอบ $2^{64}$ แทน
Score:0
ธง ca

การเข้ารหัสทุกประเภทมีค่าใช้จ่ายสูงในด้านฮาร์ดแวร์และพลังงาน ตัวคูณมีขนาดใหญ่และลึกและช้าเมื่อเทียบกับตัวบวกเต็ม ALU พื้นฐาน ฉันจะโบกมือเป็นจังหวะ แต่ถ้าคุณคว้าหนังสือสถาปัตยกรรม CPU คุณจะพบสิ่งต่อไปนี้: การออกแบบตัวคูณนั้นแตกต่างกันเสมอ แต่ไปป์ไลน์หน่วย MUL สำหรับผลลัพธ์ 64 บิตคือ 4 -deep และสำหรับผลลัพธ์ 128 บิตคือ 8-deep สำหรับ CPU ส่วนใหญ่ นี่เป็นเพราะคุณใช้บล็อกตัวบวกแบบเต็มแบบโยงใย และความลึกสูงสุดในการออกแบบ 4 ความลึกคือ 16 ความลึกของตัวบวกแบบเต็มสำหรับ XOR, ROL หรือ ADD เทียบเท่ากับตัวบวกแบบเต็มตัวเดียว โปรเซสเซอร์ Super-scaler ซ่อนความล่าช้าของตัวคูณไว้มาก อย่างไรก็ตาม หากคุณกำลังยุ่งอยู่กับปัญหาจริงๆ จะพบไปป์ไลน์ที่ว่างเปล่าพร้อมความล่าช้าอย่างมาก

โพสต์คำตอบ

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