ความแตกต่างระหว่างทฤษฎีและการปฏิบัติด้านความปลอดภัยและการเข้ารหัส?

ความแตกต่างที่น่าสนใจระหว่างทฤษฎีกับการปฏิบัติด้านความปลอดภัยและวิทยาการเข้ารหัสลับมีอะไรบ้าง

แน่นอนที่สุดจะเป็นตัวอย่างที่แนะนำลู่ทางใหม่สำหรับการวิจัยเชิงทฤษฎีจากประสบการณ์จริง :)

คำตอบอาจรวมถึง (แต่ไม่ จำกัด เฉพาะ):

• ตัวอย่างที่ทฤษฎีเสนอบางสิ่งบางอย่างที่เป็นไปได้ แต่ไม่เคยใช้ในทางปฏิบัติ
• ตัวอย่างที่ทฤษฎีแสดงให้เห็นว่าบางสิ่งบางอย่างปลอดภัยที่ไม่ปลอดภัยในทางปฏิบัติ
• ตัวอย่างของสิ่งที่ใช้กันอย่างแพร่หลายในทางปฏิบัติมีทฤษฎีเล็กน้อยอยู่ด้านหลัง

...

ข้อแม้

หากคำตอบของคุณเป็นรูปแบบ "ทฤษฎีเกี่ยวกับ asymptotics แต่การปฏิบัติไม่ใช่" ทั้งทฤษฎีควรเป็นศูนย์กลางจริง ๆ หรือคำตอบควรมีตัวอย่างเฉพาะที่ประสบการณ์การปฏิบัติในอินสแตนซ์โลกจริงแตกต่างจากความคาดหวังตาม บนทฤษฎี

ตัวอย่างหนึ่งที่ฉันรู้: การประเมินวงจรที่ปลอดภัย มีประสิทธิภาพมากในทางทฤษฎี แต่มีความซับซ้อนเกินกว่าที่จะใช้ในทางปฏิบัติเพราะมันจะเกี่ยวข้องกับการนำรหัสของคุณคลี่มันเข้าไปในวงจรแล้วทำการประเมินผลที่ปลอดภัยของแต่ละประตู

โอ้เจ้าจะเริ่มจากตรงไหนดี

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

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

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

หากต้องการดูว่าปัญหานั้นเลวร้ายเพียงใดให้พิจารณาคำแนะนำด้านความปลอดภัยนี้ที่เกี่ยวข้องกับการปลอมแปลง API ข้อผิดพลาดส่วนหนึ่งเกิดจากการโจมตีระยะยาวในการก่อสร้าง Merkle-Damgard (ซึ่งเป็นสิ่งที่พื้นฐานจริงๆ) และมีผลต่อ Flickr, DivShare, iContact, Mindmeister, Myxer, RememberTheMilk, Scribd, Vimeo, Voxel, Wizehhive และ Zoomr ผู้เขียนทราบว่านี่ไม่ใช่รายการที่สมบูรณ์

ฉันคิดว่าผู้ปฏิบัติงานสมควรได้รับส่วนแบ่งของความผิดสำหรับสถานการณ์ที่น่าเศร้านี้ ในทางกลับกันนักทฤษฎี crypto อาจจำเป็นต้องพิจารณาตำแหน่งของพวกเขาด้วยเช่นกัน สายของพวกเขาถูก: "กล่องดำเป็นไปไม่ได้ที่จะสร้าง; เราจะไม่ลองด้วยซ้ำ" ที่ฉันพูดเนื่องจากเป็นที่ชัดเจนว่าสิ่งปลูกสร้างของคุณจะได้รับ (mis) ใช้เป็นกล่องดำอยู่แล้วทำไมอย่างน้อยก็ไม่ลองทำให้มันใกล้เคียงกับกล่องดำมากที่สุด

บทความMerkle-Damgard Revisitedเป็นตัวอย่างที่ดีของสิ่งที่ฉันกำลังพูดถึง พวกเขาศึกษาแนวคิดเกี่ยวกับความปลอดภัยว่า "ฟังก์ชันแฮชความยาวตามอำเภอใจ H จะต้องทำตัวเป็นออราเคิลแบบสุ่มเมื่อการสร้างบล็อกแบบความยาวคงที่นั้นถูกมองว่าเป็นการสุ่มแบบออราเคิล การวิจัยเชิงทฤษฎีประเภทนี้มีศักยภาพที่จะเป็นประโยชน์อย่างมากในทางปฏิบัติ

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

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

เหตุใดจึงไม่มีใครใช้การประเมินฟังก์ชั่นความปลอดภัยทั่วไปในทางปฏิบัติ เป็นคำถามที่ดีมาก สิ่งนี้นำฉันไปสู่ความแตกต่างที่สองของฉันระหว่างทฤษฎีและการปฏิบัติ: เชื่อมั่นในการปฏิบัติจริง ๆ ไม่ใช่ทุกสิ่งที่จะต้องทำในแบบจำลองหวาดระแวง ชุดของปัญหาที่ผู้คนต้องการแก้ไขโดยใช้ crypto นั้นจริง ๆ แล้วเล็กกว่าสิ่งที่ cryptographers จินตนาการ

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

จุดแตกต่างสุดท้ายของฉันระหว่างทฤษฎีและการปฏิบัติคือเกี่ยวกับ PKI เอกสาร Crypto ติดประโยคหนึ่งบ่อยครั้งว่า "เราถือว่าเป็น PKI" น่าเสียดายที่ใบรับรองดิจิทัลสำหรับผู้ใช้ปลายทาง (ตรงข้ามกับเว็บไซต์หรือพนักงานในบริบทขององค์กรซึ่งมีลำดับชั้นตามธรรมชาติ) ไม่เคยปรากฏ บทความคลาสสิคนี้อธิบายถึงความฮือฮาที่เกิดขึ้นเมื่อคุณขอให้คนทั่วไปใช้ PGP ฉันบอกแล้วว่าซอฟต์แวร์นั้นพัฒนาขึ้นมากมายตั้งแต่นั้นมา แต่ปัญหาด้านการออกแบบและสถาปัตยกรรมและข้อ จำกัด ของมนุษย์ในปัจจุบันไม่ได้แตกต่างกันมากนัก

ฉันไม่คิดว่า cryptographers ควรทำอะไรที่แตกต่างไปจากการขาด PKI ในโลกแห่งความเป็นจริงนี้ยกเว้นที่จะตระหนักถึงความจริงที่ว่ามัน จำกัด การบังคับใช้โปรโตคอลเข้ารหัสลับในโลกแห่งความเป็นจริง ฉันขว้างมันเข้าไปเพราะมันเป็นสิ่งที่ฉันพยายามจะแก้ไข

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

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

การเข้ารหัส Homomorphic และการสื่อสารแบบหลายส่วนที่ปลอดภัยเป็นสองสิ่งสำคัญที่ค้นพบล่าสุดในการเข้ารหัสซึ่งยังไม่ได้รับการศึกษาอย่างเพียงพอที่จะนำไปใช้ได้จริง: ความพยายามในการวิจัยเช่นPROCEEDกำลังดำเนินไปในทิศทางนี้เพื่อระบุว่า การเรียงลำดับของการคำนวณตลอดจนค้นหาการปรับให้เหมาะสมกับอัลกอริทึมการเข้ารหัสลับหลักที่ทำให้พวกเขาทำงานในเวลาที่เหมาะสม นี่เป็นเหตุการณ์ที่เกิดขึ้นทั่วไปในการเข้ารหัส: เราเริ่มต้นด้วย (เปรียบเทียบ) อัลกอริทึมแบบง่ายที่ใช้เวลานานในการทำงานแล้ว cryptographers ใช้เวลาหลายปีในการใช้คณิตศาสตร์เพื่อเพิ่มประสิทธิภาพอัลกอริธึมเพิ่มเติมและไกลออกไป

ตัวอย่างที่ทฤษฎีเสนอบางสิ่งบางอย่างที่เป็นไปได้ แต่ไม่เคยใช้ในทางปฏิบัติ:

มันค่อนข้างง่ายที่จะหาตัวอย่างของสิ่งต่าง ๆ ที่แก้ไขได้ในทางทฤษฎี แต่ (1) นั้นไม่มีประสิทธิภาพเกินกว่าที่จะใช้ในทางปฏิบัติหรือ (2) ไม่มีใครสนใจ ตัวอย่าง: (1) (ทั่วไป) การพิสูจน์ความรู้เป็นศูนย์ (2) ลายเซ็นที่ไม่อาจปฏิเสธได้ ในความเป็นจริงดูการประชุม crypto ใด ๆ และอย่างน้อยครึ่งหนึ่งของเอกสารอาจจะตกอยู่ในหมวดหมู่เหล่านี้

ตัวอย่างที่ทฤษฎีแสดงให้เห็นว่าบางสิ่งบางอย่างปลอดภัยที่ไม่ปลอดภัยในทางปฏิบัติ:

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

ตัวอย่างของสิ่งที่ใช้กันอย่างแพร่หลายในทางปฏิบัติมีทฤษฎีเล็กน้อยอยู่ด้านหลัง:

ฉันถือว่าคุณหมายถึงในโลกเข้ารหัสลับไม่ใช่ในโลกความปลอดภัยทั่วไป ตัวอย่างที่ดีคือลายเซ็น DSS ซึ่งไม่มีหลักฐานความปลอดภัย

$M$$M'$$M'$$w \iff M$$w$$M'$$w \iff M$$w$$M'$$M$$M'$$M$

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

มีวิธีการเชิงทฤษฎีเกี่ยวกับปัญหาของการทำให้งงงวยที่ทำให้ความต้องการของอุตสาหกรรมเป็นทางการ แต่ขึ้นอยู่กับความเชื่อมั่นที่เข้มงวดมากขึ้นของความปลอดภัยบนพื้นฐานของความสามารถในการคำนวณได้ (ลองจินตนาการถึงการแทนที่การทดสอบจำนวนเต็ม โดยเฉพาะอย่างยิ่งการศึกษาการทำให้งอจุดประกอบที่ซับซ้อนได้รับการพัฒนาเพื่อพยายามแก้ปัญหาการทำให้งงที่น่าสนใจสำหรับอุตสาหกรรม แต่น่าเสียดายที่กว้างที่สุดในการแพร่กระจายรูปแบบทางทฤษฎีสำหรับ obfuscation ตามรูปแบบแรงบันดาลใจจากฮาร์ดแวร์หลักฐานยุ่งได้รับผลที่เป็นไปไม่ได้ในปี 2001 โดย Barak et al, ในกระดาษ " ใน (IM) เป็นไปได้ของ obfuscating โปรแกรม " (รุ่นอื่น ๆ หลายรุ่นก็ได้รับผลลัพธ์ที่เป็นไปไม่ได้เช่นกัน)

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

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

มีช่องว่างที่สำคัญแม้เมื่อพูดถึงพื้นฐานดั้งเดิมเช่นเครื่องกำเนิดไฟฟ้าหลอกเทียม ลองพิจารณาฟังก์ชั่น pseudorandom ในทางปฏิบัติผู้คนใช้สิ่งต่าง ๆ เช่นAESซึ่งแตกต่างจากผู้สมัครทางทฤษฎี (Goldreich, Goldwasser, Micali; Naor, Reingold; ฯลฯ ) ในหลายมิติ: ประการแรกพารามิเตอร์แตกต่างกันอย่างสิ้นเชิงเช่น AES สามารถมีความยาวคีย์ซึ่งเท่ากับความยาวอินพุต ซึ่งไม่เคยได้ยินมาก่อนในทฤษฏีการก่อสร้าง บางทีที่สำคัญกว่านั้น AES (และบล็อกเลขบล็อกอื่น ๆ ) ติดตามกระบวนทัศน์เครือข่ายการเปลี่ยนรูปแบบการสับเปลี่ยนที่เรียกว่าค่อนข้างแตกต่างจากวิธีที่ทฤษฏีการก่อสร้างไป (เช่นที่กล่าวถึงข้างต้น)

แน่นอนที่สุดจะเป็นตัวอย่างที่แนะนำลู่ทางใหม่สำหรับการวิจัยเชิงทฤษฎีจากประสบการณ์จริง :)

ฉันคิดว่าตัวอย่างข้างต้นเป็นตัวอย่างให้ดูตัวอย่างบทความนี้กับ Eric Miles (ซึ่งคำตอบนี้ถูกนำมาใช้เป็นหลัก)