Tags:
Node Thumbnail

ในบรรดากระบวนการเข้ารหัสนั้น เราอาจจะบอกได้ว่าการเข้ารหัสแบบกุญแจสมมาตร (symmetric key) ที่เป็นกระบวนการการเข้ารหัสที่ทั้งสองฝ่าย มี “ความลับ” ร่วมกันอยู่ก่อน เมื่อส่งข้อมูลจริงแล้วจึงใช้ความลับนั้นถอดรหัสผ่านออกมาได้จึงได้ข้อความที่อ่านออกมาได้

กระบวนการป้องกันข้อความที่เป็นความลับนั้นมีมานานนับย้อนไปได้ถึงสมัยจูเลียส ซีซาร์ ที่อาศัยการสลับตัวอักษรด้วยตารางที่เป็นความลับ โดยทุกตัวในตารางจะมีตัวแทนของตัวเองทั้งหมด

การเข้ารหัสนี้ได้ผลดีอยู่หลายร้อยปี ข้อความที่สำคัญถูกแปลงเป็นข้อความที่อ่านไม่ออก เช่นหากเราแปลงข้อความด้วยการเลื่อนตัวอักษรไปเป็น 13 ตัวข้างหน้า (มีชื่อเรียกเฉพาะว่าการเข้ารหัสแบบ rot13) ข้อความทางการทหารอย่าง “FALLING BACK PLEASE WAIT FOR ME” (กำลังล่าถอย รอด้วย) จะถูกแปลงเป็นข้อความที่อ่านไม่ออกอย่าง “SNYYVAT ONPX CYRNFR JNVG SBE ZR” ทดลองเล่นการเข้ารหัสได้ใน forret.com

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

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

แม้จะสร้างตารางที่ความเป็นไปได้มากด้วยการสร้างตารางที่ไม่ได้อาศัยการหมุนวงล้อ ความอ่อนแอของระบบการเข้ารหัสแบบนี้ก็ถูกพบในช่วงศตวรรษที่ 9 (ค.ศ. 800 ถึง ค.ศ. 900) ว่าในความเป็นจริงแล้วเราสามารถถอดรหัสรูปแบบนี้ได้หากเรารู้คุณสมบัติของ “ภาษา” ที่เราใช้เสียก่อน เช่น ภาษาอังกฤษนั้นตัว E จะเป็นตัวอักษรที่ถูกใช้งานมากเป็นอันดับแรก และตัว A เป็นอันดับที่สอง รวมถึงคุณสมบัติเช่น ตัวอักษรที่อยู่เดียวๆ นั้นมักจะเป็นตัว A ตัวอักษรที่แยกเป็น 3 ตัวมักเป็นคำว่า THE กระบวนการเช่นนี้ทำให้หากข้อความยาวเพียงพอ หรือมีการส่งข้อความด้วยตารางรหัสเดิมมากพอ ผู้ดักฟังก็จะถอดรหัสได้อย่างรวดเร็ว

One Time Pad

กระบวนการสร้างตารางเปลี่ยนรหัสผ่าน ถูกแปลงมาอีกครั้งด้วยคำถามใหม่ว่า จะเป็นอย่างไรถ้าเรามีตารางสำหรับ “ทุกตัวอักษร” ในข้อความนั้นๆ ดังตัวอย่าง

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

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

No Description

ข้อมูลที่เป็นเลขไบนารีสุ่มนี้ทำให้เราเรียกการเข้ารหัสแบบนี้ว่า One Time Pad คือเมื่อเรามีตัวเลขสุ่มที่แชร์ระหว่างต้นทางและปลายทาง คนที่มองเห็นข้อมูลที่เข้ารหัสแล้วจะไม่มีทางถอดรหัสโดยแน่ใจว่าข้อมูลนั้นถูกต้องได้เลย กระบวนการรักษาความปลอดภัยข้อมูลเช่นนี้จึงเป็นตัวอย่างหนึ่งของการรักษาความปลอดภัยที่ปลอดภัยโดยไร้เงื่อนไข (unconditionally secure)

แต่ข้อจำกัดของ One Time Pad คือมันจะปลอดภัยก็ต่อเมื่อมีการใช้งานเพียงครั้งเดียวเท่านั้น เพราะการใช้งานซ้ำ ในแต่ละตัวอักษรจะรู้ได้ทันทีว่าเป็นข้อมูลเดิมหรือไม่ หากมีการใช้งาน One Time Pad กับข้อมูลที่ต่างกันบ่อยครั้งมากๆ สุดท้ายคนที่ดักฟังได้ก็จะสามารถรู้ได้ว่าข้อมูลที่ส่ง และกุญแจที่ส่งนั้นคืออะไร

Stream Cipher

ในโลกความเป็นจริง การเข้ารหัสแบบ One Time Pad นั้นนับว่าเป็นกระบวนการที่ลำบาก โดยเฉพาะในแง่ของความเร็ว ที่ข้อมูลสำหรับการเข้ารหัสจะมีขนาดใหญ่เท่าๆ กับตัวข้อมูลเอง ในแง่ของการลดภาระในการส่งกุญแจที่ต้องมีขนาดเท่ากับตัวข้อมูล จึงมีการสร้างระบบเข้ารหัสที่เรียกว่า stream cipher ขึ้นมา

stream cipher โดยหลักการแล้วมันคือการใช้ค่าจากฟังก์ชั่น pseudo random number generator (PRNG) เพื่อสร้างข้อมูลไบนารีขนาดยาวขึ้นมา โดยค่าเริ่มต้นของ PRNG นั้นเป็นค่าความลับที่ผู้รับและผู้ส่งแชร์ระหว่างกัน ข้อมูลนั้นมักมีขนาดเล็ก แต่สามารถสร้างไบนารีแบบสุ่มที่มีขนาดใหญ่ขึ้นมาเพื่อ XOR กับข้อมูลทั้งหมดที่ต้องการเข้ารหัสได้ ตัวอย่างการใช้งานในรูปแบบนี้ได้แก่การเข้ารหัสแบบ A5/1 ในโทรศัพท์ GSM ที่ใช้ฟังก์ชั่นในตระกูล LFSR ที่เป็นฟังก์ชั่น PRNG ตัวหนึ่ง หรือใน WEP ของระบบแลนไร้สายที่ใช้ฟังก์ชั่น RC4 เป็นตัวสร้างไบนารีเช่นกัน

การเข้ารหัสแบบ SSL RC4_128 เป็นการเข้ารหัสแบบแบบ stream cipher ที่เว็บขนาดใหญ่ล้วนใช้งานจากความได้เปรียบด้านความเร็ว และการส่งข้อมูลที่เป็นชุดที่วิ่งอยู่บนโปรโตคอล TCP ที่ช่วยลดปัญหาข้อมูลสูญหายระหว่างทางไปแล้ว

Block Cipher

การทำ stream cipher แม้จะแก้ปัญหากุญแจเข้ารหัสมีขนาดใหญ่ไปได้ แต่การที่กุญแจเข้ารหัส ซึ่งกลายเป็นค่าเริ่มต้นสำหรับ PRNG นั้นมีขนาดเล็ก ทำให้ความปลอดภัยโดยรวมนั้นลดลงอย่างหลีกเลี่ยงไม่ได้ เช่นหากค่าเริ่มต้นของฟังก์ชั่น PRNG ความเป็นไปได้เพียง 2^32 ค่า (ขนาดกุญแจมีขนาด 32 บิต) ผู้ดักฟังข้อมูลไปได้ ก็อาจจะไล่ค่าที่เป็นไปได้เรื่อยๆ แล้วดูว่าค่าใดที่ให้ข้อมูลไบนารีแบบสุ่มแล้วนำไป XOR กับข้อมูลเข้ารหัสแล้วได้ค่าที่มีความหมายแสดงว่าได้เจอกุญแจที่ถูกต้องแล้ว แม้การขยายขนาดกุญแจไปเรื่อยๆ ในทุกวันนี้หากข้อมูลที่ส่งไประหว่างทางมีการตรวจสอบความถูกต้อง กุญที่ถอดรหัสแล้วสามารถตรวจสอบความถูกต้องได้ก็มีความเป็นไปได้สูงว่าจะมีเพียงกุญแจเดียว จากกุญแจที่เป็นไปได้จำนวนมหาศาล กระบวนการเช่นนี้ทำให้ความปลอดภัยโดยรวมของ stream cipher นั้นต่ำกว่า one time pad อยู่ ในโลกความเป็นจริง การเข้ารหัสแม้จะเป็น stream cipher มักจะใช้กุญแจขนาดใหญ่กว่า 128 บิตขึ้นไปเพื่อรับประกันได้ว่าจะไม่มีใครสามารถไล่กุญแจทุกกุญแจที่เป็นไปได้ภายในช่วงเวลาหลายสิบปีข้างหน้า

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

สำหรับข้อมูลที่ต้องการใช้งานเป็นส่วนๆ ได้ จึงมีการเข้ารหัสแบบ block cipher มาอีกแบบหนึ่งให้เลือกใช้งาน ในตระกูล block cipher นั้นอัลกอริทึมที่ได้รับความนิยมสูงตัวแรกๆ คือ DES หรือ Data Encryption Standard ที่ถูกออกแบบโดย Horst Feisel ที่ทำงานอยู่ในไอบีเอ็มช่วงปี 1977 และได้รับบรรจุเป็นกระบวนการเข้ารหัสมาตรฐานสำหรับรัฐบาลกลางสหรัฐฯ นับแต่นั้นมา ตัวอัลกอริทึม DES นั้นออกแบบให้เข้ารหัสข้อมูลทีละ 64 บิต ด้วยกุญแจขนาด 56 บิต โดยตัวฟังก์ชั่นเองยังไม่สามารถพิสูจน์ได้ว่ามีความปลอดภัยจริงหรือไม่ แต่อายุกว่าสามสิบปีของ DES ก็ยังมีความปลอดภัยตามที่ออกแบบเอาไว้ นั่นคือผู้ที่จะแฮกได้ต้องทดสอบกุญแจถึง 2^56 รูปแบบเพื่อหากุญแจที่ถูกต้องในการถอดรหัส DES นับเป็นตัวอย่างหนึ่งของฟังก์ชั่นความปลอดภัยที่ปลอดภัยจากประสบการณ์ที่ผ่านมา (empirically secure)

กุญแจ 2^56 ที่เคยใหญ่พอในยุคของช่วงปี 1970 ซึ่งคอมพิวเตอร์ยังทำงานได้ช้ากว่าทุกวันนี้มาก ทำให้หลายคนยังเชื่อในประสิทธิภาพของฟังก์ชั่น DES เอง แล้วพัฒนามันด้วยการเข้ารหัสซ้ำๆ ไปเป็นจำนวนสามรอบ กลายเป็นฟังก์ชั่น 3DES หรือ Triple DES ที่มีขนาดกุญแจ 168 บิต ทุกวันนี้กระบวนการจ่ายเงินผ่านบัตรเครดิตสมาร์ตการ์ดต่างๆ ยังคงใช้การเข้ารหัสแบบ 3DES เป็นส่วนประกอบสำคัญในการรักษาความปลอดภัย

แต่ระหว่างที่ DES ถูกพิสูจน์ว่าไม่ปลอดภัยนั้น สถาบันมาตรฐานและเทคโนโลยีของสหรัฐฯ (National Institute of Standards and Technology - NIST) ก็จัดประกวดมาตรฐานการเข้ารหัส และอัลกอริทึมของ Joan Daemen และ Vincent Rijmen นักคณิตศาสตร์ชาวเบลเยียมก็ชนะการประกวดด้วยอัลกอริทึมที่ปรับปรุงจากอัลกอริทึมเข้ารหัสของตัวเองที่ชื่อว่า Rijndael จนกระทั่งชนะการประกวดและเวอร์ชั่นที่พัฒนาแล้วของ Rijndael ก็กลายเป็นอัลกอริทึม AES ในทุกวันนี้ ในช่วงสิบปีมานี้ มีแนวโน้มที่ระบบการเข้ารหัสใหม่ๆ จะใช้ AES มาเป็นอัลกอริทึมหลักมากขึ้นเรื่อยๆ กระบวนการเข้ารหัส AES ถูกบรรจุเข้าไปในมาตรฐานเช่น SSL, WPA เพื่อรับประกันว่าจะทนทานต่อการเจาะรหัส และเนื่องจากความนิยมที่เพิ่มขึ้นซีพียูรุ่นใหม่ๆ เริ่มมีชุดคำสั่งเร่งการทำงานของ AES เพิ่มเข้ามา ความนิยมของการเข้ารหัสแบบ AES จึงน่าจะได้รับความนิยมสูงขึ้นเรื่อยๆ ในอนาคต

Block Cipher Operation Mode

กระบวนการเข้ารหัสเป็นบล็อคนั้นมีปัญหาเช่นเดียวกับการเข้ารหัสแบบอื่นๆ คือการใช้กุญแจเดิมๆ ซ้ำๆ นั้นจะให้ทำให้ได้ข้อมูลแบบเดิมออกมาเรื่อยๆ แม้ว่าฟังก์ชั่นการเข้ารหัสแบบใหม่ๆ จะทำให้การวิเคราะห์ว่าข้อมูลที่แท้จริงเป็นอะไรนั้นทำได้ยาก แต่หลายครั้งการที่แฮกเกอร์เห็นว่ามีข้อมูลแบบเดิม (ที่ไม่รู้ว่าเป็นอะไร) เดินทางซ้ำๆ บ่อยเพียงใดก็สามารถเปิดเผยข้อมูลบางอย่างได้แล้ว กระบวนการเข้ารหัสเป็นบล็อคที่พื้นฐานที่สุดนั้น เราเรียกว่าโหมด Electronic Code Book (ECB) การทำงานของมันคือการแบ่งข้อมูลออกเป็นบล็อคๆ ตามอัลกอริทึมที่เลือกใช้ เช่น 128 บิตสำหรับ AES หรือ 64 บิตสำหรับ DES แล้วเข้ารหัสด้วยกุญแจที่กำหนด

No DescriptionNo Description

กระบวนการนี้แม้จะมองไม่ออกว่าข้อมูลเป็นอะไร แต่เมื่อมองข้อมูลในภาพรวมแล้วเราก็อาจจะเห็นได้ว่าข้อมูลที่แท้จริงคืออะไร กระบวนการแบบ ECB จึงไม่แนะนำนัก

เพื่อให้ข้อมูลทุกบล็อคแตกต่างกันออกไปอย่างแท้จริง มีการเสนอกระบวนการ Cipher Block Chaining (CBC) และ Cipher Feedback (CFB) ขึ้นมา โดยหลักการแล้วทั้งสองแบบคล้ายกันคือใช้ข้อมูลที่เข้ารหัสแล้วของบล็อคก่อนหน้าเพื่อเป็นส่วนประกอบของกุญแจเข้ารหัสของบล็อคถัดไป กระบวนการเช่นนี้ทำให้แม้จะส่งข้อมูลเดิมซ้ำๆ ไปเรื่อยๆ ข้อมูลที่ถอดรหัสแล้วก็จะเปลี่ยนไปไม่รู้จบ

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

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

กระบวนการเข้ารหัสแบบ CTR ถูกดัดแปลงไปใช้งานในมาตรฐานเข้ารหัส WEP ที่ตัวเลขขนาด 24 บิตเรียกว่า initial vector (IV) จะถูกส่งติดไปกับทุกแพ็กเก็ต เพื่อใช้ประกอบกับกุญแจลับในการเข้ารหัส แต่ตัวเลขขนาด 24 บิตนี้นับว่ามีขนาดเล็กมาก และสิ่งที่เกิดขึ้นคือการ์ดแลนไร้สายบางรุ่นพยายามใช้ค่า IV ในแบบสุ่ม แต่การสุ่มที่ดีกลับทำให้ความน่าจะเป็นที่จะใช้ค่า IV นี้ซ้ำกันเกิดขึ้นได้ง่ายในทุกๆ 4096 แพ็กเก็ตเท่านั้น (ปัญหาสุ่มเลขซ้ำนี้เรียกว่า birthday paradox ที่ระบุว่าในกลุ่มคนเพียง 57 คนจะมีวันเกิดวันเดือนเดียวกันด้วยความน่าจะเป็น 0.99) เมื่อเกิดการใช้ค่า IV ซ้ำกัน ค่าไบนารีที่ได้จาก RC4 ก็จะเหมือนกันทุกประการ และแฮกเกอร์ก็จะสามารถคาดเดาได้ว่าข้อมูลภายในเป็นอะไรเมื่อพบข้อมูลที่ใช้ค่า IV เดิมซ้ำกันมากขึ้นเรื่อยๆ แบบเดียวกับการใช้ One Time Pad ซ้ำๆ กัน

การเข้ารหัสแบบ ใช้กุญแจร่วมกันทั้งสองฝั่งนั้นยังมีการพัฒนาในรูปแบบอื่นๆ อีกจำนวนมาก การเข้ารหัสเป็นบล็อคยุคใหม่มักใส่กระบวนการพิสูจน์ความถูกต้องของข้อมูลเข้าไว้เป็นมาตรฐานเดียวกับ เช่น CBC-MAC ที่รวมเอาการรวจสอบความถูกต้องเข้ามาร่วมกับการเข้ารหัสเป็นบล็อคในโหมด CBC มาตรฐานใหม่ๆ เช่น Offset Codebook (OCB) ถูกเสนอเป็นทางเลือกของแลนไร้สายแต่กลับไม่ได้รับความนิยมเพราะติดปัญหาสิทธิบัตร

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

บทความนี้เขียนจบตอนตีสาม และผมนึกวิดีโอมาจบท้ายให้เข้ากับหัวข้อไม่ออก :P

Get latest news from Blognone

Comments

By: hisoft
ContributorWindows PhoneWindows
on 27 May 2013 - 04:26 #578372
hisoft's picture

ขอบคุณสำหรับบทความดี ๆ อีกแล้วครับ ^^

หลีเลี่ยง => หลีกเลี่ยง

เรือย => เรื่อย (ไม้เอกหาย)

"กุญ" ที่ถอดรหัส => "กุญแจ" หรือเปล่าครับ?

เรือ่ย => เรื่อย

การ์ต => การ์ด

และอัลกอริทึมของ Joan Daemen และ Vincent Rijmen นักคณิตศาสตร์ชาวเบลเยียมก็ชนะการประกวดด้วยอัลกอริทึมที่ปรับปรุงจากอัลกอริทึมเข้ารหัสของตัวเองที่ชื่อว่า Rijndael ในช่วงสิบปีมานี้ มีแนวโน้มที่ระบบการเข้ารหัสใหม่ๆ จะใช้ AES มาเป็นอัลกอริทึมหลักมากขึ้นเรื่อยๆ

ตกลงว่า Rijndael ถูกปรับปรุงเป็นอัลกอริทึมชื่ออะไรครับ? ใช่ AES หรือเปล่า

ยางอย่าง => บางอย่าง หรือเปล่าครับ?

อัลกอริทืม => อัลกอริทึม

By: asptuy
Windows PhoneAndroidWindows
on 27 May 2013 - 04:43 #578375 Reply to:578372
asptuy's picture

Rijindael ไม่น่าใช่ AES ผมใช้อยู่

By: hisoft
ContributorWindows PhoneWindows
on 27 May 2013 - 04:54 #578379 Reply to:578375
hisoft's picture

มันเขียนต่อกันแบบชวนสับสนน่ะครับ

By: luckyman
ContributoriPhoneAndroidRed Hat
on 27 May 2013 - 11:59 #578471 Reply to:578372

ใช่ครับ Rijndael -> AES

By: asptuy
Windows PhoneAndroidWindows
on 27 May 2013 - 04:44 #578376
asptuy's picture

เดี๋ยวตื่นมาอ่านล่ะกัน

By: kitarotao
iPhoneWindows PhoneAndroidBlackberry
on 27 May 2013 - 05:29 #578383
kitarotao's picture
By: oatsmart
iPhoneWindows PhoneAndroidWindows
on 27 May 2013 - 06:34 #578390
oatsmart's picture

ชอบอะ อ่านแล้วเพลินดี

By: Blogger
AndroidUbuntuWindows
on 27 May 2013 - 09:20 #578412

ได้ความรู้ สุดๆ

By: SomeThing
Windows
on 27 May 2013 - 09:24 #578416

ดูท่าทางช่วงนี้คุณหลิวสนใจ Security เป็นพิเศษ

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

รออ่านภาคต่อครับ

By: shikima
Windows PhoneAndroidUbuntu
on 27 May 2013 - 14:41 #578572 Reply to:578416

ถ้าใช้เวลาเป็น key ละครับ

ตามความคิดของผม ใช้ timestamp นี่แหละ แต่ต้องตั้งเวลาของทั้งผู้รับ และ ปลายทาง ให้เหมือนกัน key อาจจะเปลี่ยนทุก 5 นาที ก่อนส่งอาจเอาไป mod อะไรสักอย่าง หรือใส่เกลือ (salt) เข้าไปนิดหน่อย

ผมทำแบบนี้ เวลาเขียนโปรแกรมที่ต้องส่งข้อมูลระหว่าง server อ่ะครับ ถ้างานที่ต้องการความมั่นคงสูงๆ ก็คงต้องซับซ้อนกว่านี้ แต่งานของผมมันไม่ขนาดนั้นอ่ะ ^_^

By: hisoft
ContributorWindows PhoneWindows
on 27 May 2013 - 15:12 #578580 Reply to:578572
hisoft's picture

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

Diffie–Hellman key exchange

ตรงกับประเด็นที่คุยกันอยู่หรือเปล่าก็ไม่รู้นะครับ ผมก็มึน 555

By: lunatic on 27 May 2013 - 19:02 #578675 Reply to:578580
lunatic's picture

สงสัยอย่างนึงคือ Diffie Hellman

เนี่ยถ้าคนที่คุยกับ client ตั้งแต่แรกเป็น server ปลอมจะทำยังไง

ความลับ ก็ไม่ปลอดภัยเหมือนกัน

By: hisoft
ContributorWindows PhoneWindows
on 27 May 2013 - 19:46 #578684 Reply to:578675
hisoft's picture

เนี่ยถ้าคนที่คุยกับ client ตั้งแต่แรกเป็น server ปลอมจะทำยังไง

ทำ..ใจครับ :D

By: Onewings
Windows
on 27 May 2013 - 20:49 #578705 Reply to:578675

Man-in-the-middle attack ยอดนิยมไงครับ มันต้องคุยกันด้วยความเชื่อใจว่า server ที่เราใช้เป็นของจริงด้วยการยืนยันตัวพวก root CA ที่ Verify by XXXX พวกนี้ไงครับ

By: SomeThing
Windows
on 27 May 2013 - 19:55 #578688 Reply to:578580

ตรงนะครับ ก็เป็นวิธีการแลกคีย์อย่างหนึ่งเหมือนกัน
บทหนักมาตกอยู่ที่อัลกอริทึมทดสอบว่าเป็น prime มั๊ยอีก ยิ่งค่าใหญ่เทสกันเหนื่อย + นาน
เกิดเลือกมาใช้ไม่ได้เทสใหม่อีก

By: Onewings
Windows
on 27 May 2013 - 13:50 #578537

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

By: lew
FounderJusci's WriterMEconomicsAndroid
on 27 May 2013 - 16:22 #578610 Reply to:578537
lew's picture

quantum นี่พูดกันมานานแต่ในโลกความเป็นจริงก็ยังไม่มีใครใช้ครับ AES มีช่องโหว่สำคัญคือในกรณี related-key (สามารถหาความเชื่อมโยงระหว่างกุญแจการเข้ารหัสแต่ละชุด) แม้จะน่าสนใจและต้องระวังแต่การโจมตีก็ยังจำกัดมาก ต่อให้เจาะได้ในทางปฏิบัติจริง ก็มีแนวโน้มสูงว่าในอนาคตจะพัฒนาการเข้ารหัสแบบเดิมๆ แต่ขยายขนาดกุญแจออกไป อย่างตอนนี้ก็เริ่มมีการเสนอ AES-512 มาบ้างแล้ว แต่ยังไม่ได้รับการยอมรับเท่าไหร


lewcpe.com, @public_lewcpe

By: javaboom
WriteriPhone
on 27 May 2013 - 21:23 #578718
javaboom's picture

เยี่ยมมากครับ


My Blog

By: scarface
iPhoneAndroidBlackberry
on 28 May 2013 - 00:02 #578763
scarface's picture

ผมจะไม่บอกว่าบทความนี้ดีหรือไม่

แต่เหนือสิ่งอื่นใดผมก็เชื่อว่าคนเขียนบทความนี้เจ๋งมาก
ที่กล้าไปเอาเรื่องยากๆมาเล่าสู้กันฟัง
บอกตรงๆ บทความเรื่องพวกนี้ไม่มีแปลเป็นไทยให้อ่านกันเท่าไหร่นะครับ

By: Virusfowl
ContributorAndroidSymbianWindows
on 31 May 2013 - 23:16 #580776

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

  • กุญที่ถอดรหัสแล้ว > กุญแจที่ถอดรหัสแล้ว

การเข้ารหัสเป็นบล็อคยุคใหม่มักใส่กระบวนการพิสูจน์ความถูกต้องของข้อมูลเข้าไว้เป็นมาตรฐานเดียวกับ เช่น CBC-MAC ที่รวมเอาการรวจสอบความถูกต้องเข้ามาร่วมกับการเข้ารหัสเป็นบล็อคในโหมด CBC มาตรฐานใหม่ๆ

  • มาตรฐานเดียวกับ > มาตรฐานเดียวกัน
  • การรวจสอบ > การตรวจสอบ

ยอมรับว่าในชุดบทความที่มีมานี้ อันนี้เป็นอันที่อ่านแล้วเข้าใจได้น้อยที่สุด T_T รู้สึกว่าตัวเองไม่ค่อยมีหัวด้านการเข้ารหัสเท่าไหร่แฮะ ตั้งแต่ลองไปอ่านบล็อกคุณเนยสดละ :'(


@ Virusfowl

I'm not a dev. not yet a user.