- การเข้ารหัสโฮโมมอร์ฟิกแบบสมบูรณ์ (FHE) คือเทคโนโลยีที่สามารถคำนวณบนข้อมูลที่ยังอยู่ในสภาพ ciphertext ได้โดยไม่ต้องถอดรหัส
- ปัจจุบัน FHE ยังมีข้อจำกัดด้าน การใช้งานจริงที่ยังต่ำ โดยความเร็วในการคำนวณช้าลง 1,000 เท่า~10,000 เท่า และต้องใช้พื้นที่จัดเก็บเพิ่มขึ้น 40 เท่า~1,000 เท่า
- แต่ในช่วงหลัง อัลกอริทึม FHE มี ความเร็วเพิ่มขึ้น 8 เท่าต่อปี และมีแนวโน้มว่าจะเข้าสู่ระดับใช้งานจริงได้ในไม่ช้าในงานอย่างคลาวด์คอมพิวติง, การอนุมาน LLM และสมาร์ตคอนแทรกต์บนบล็อกเชน
- หาก FHE ถูกใช้อย่างแพร่หลาย ก็จะผลักดันการเปลี่ยนแปลงระดับอุตสาหกรรมที่ทำให้ ความเป็นส่วนตัวของข้อมูลกลายเป็นค่าเริ่มต้นของสภาพแวดล้อมการประมวลผลทั้งหมด
- ครอบคลุมแนวคิดสำคัญอย่าง การเข้ารหัสแบบ lattice-based, LWE, bootstrapping รวมถึงพัฒนาการของอัลกอริทึม FHE ตัวอย่างการนำไปใช้จริง และแนวโน้มการปรับปรุงประสิทธิภาพ
บทนำ: การเข้ารหัสโฮโมมอร์ฟิกแบบสมบูรณ์คืออะไร
- การเข้ารหัสโฮโมมอร์ฟิกแบบสมบูรณ์ (Fully Homomorphic Encryption, FHE) คือวิธีที่ทำให้สามารถคำนวณใดๆ บน ciphertext ได้โดยไม่ต้องถอดรหัส จึงสามารถ คำนวณบนข้อมูลที่ถูกเข้ารหัสได้โดยตรง
- กล่าวคือ เซิร์ฟเวอร์สามารถคำนวณคำถามและผลลัพธ์แล้วส่งกลับมาได้โดยไม่ต้องรู้ plaintext
- เทคโนโลยีนี้กำลังถูกนำไปใช้จริงในหลายระบบของโลกจริงในปัจจุบัน
ศักยภาพและข้อจำกัดของ FHE: "กฎของมัวร์สำหรับ FHE"
- FHE สามารถทำให้ข้อมูลคงอยู่ในสภาพเข้ารหัสตลอดเวลาบนเครือข่าย จึงทำให้เกิด ความเป็นส่วนตัวอย่างสมบูรณ์ ที่ปิดความเสี่ยงการรั่วไหลของข้อมูลได้ตั้งแต่ต้นทาง
- อย่างไรก็ตาม เหตุผลที่ยังมีข้อจำกัดด้านการใช้งานจริงในตอนนี้ คือการคำนวณบน ciphertext ช้ากว่าการคำนวณบน plaintext ราว 1,000~10,000 เท่า และยังต้องใช้พื้นที่จัดเก็บเพิ่มขึ้นประมาณ 40~1,000 เท่า ซึ่งเป็น การลดลงของประสิทธิภาพอย่างมาก
- สถานการณ์นี้คล้ายกับยุคเริ่มต้นของอินเทอร์เน็ตในช่วงทศวรรษ 1990
- แต่ช่วงหลัง FHE เร็วขึ้น 8 เท่าทุกปี จึงถูกคาดหมายว่าจะเข้าสู่การใช้งานจริงในหลายด้านในไม่ช้า
จุดเปลี่ยน: การใช้งานจริงของ FHE ที่กำลังใกล้เข้ามา
- หากการพัฒนาแบบก้าวกระโดดด้านความเร็วนี้ยังดำเนินต่อไป ในอนาคต FHE อาจถูกใช้งานจริงได้ในสาขาต่อไปนี้
- คลาวด์คอมพิวติงแบบเข้ารหัส
- การอนุมาน LLM แบบเข้ารหัส
- สมาร์ตคอนแทรกต์บนบล็อกเชนที่รักษาความลับได้
- การเปลี่ยนแปลงเช่นนี้อาจสั่นคลอนโมเดลธุรกิจอินเทอร์เน็ตที่ตั้งอยู่บนการเก็บรวบรวมข้อมูลผู้ใช้โดยพื้นฐาน
- FHE ทำให้คาดหวังได้ถึง การเปลี่ยนผ่านเชิงแก่นสาร จากอินเทอร์เน็ตที่ "การเฝ้าติดตามเป็นค่าเริ่มต้น" ไปสู่อินเทอร์เน็ตที่ "ความเป็นส่วนตัวเป็นค่าเริ่มต้น"
จุดอ่อนสำคัญของความปลอดภัยข้อมูลและทางออกของ FHE
- ข้อมูลมีอยู่ใน 3 สถานะคือ ขณะจัดเก็บ, ขณะส่งผ่าน, และขณะใช้งาน โดยสถานะ 'ขณะใช้งาน' มักต้องถูกถอดรหัสและกลายเป็นช่องโหว่ด้านความปลอดภัย
- ไม่ว่าจะเป็นคลาวด์, บุคคลภายใน, แฮ็กเกอร์ หรือ CPU ที่มีช่องโหว่ ต่างก็อาจเข้าถึง ข้อมูล plaintext ในหน่วยความจำได้
- เหตุข้อมูลรั่วไหลขนาดใหญ่ส่วนมากก็เกิดขึ้นระหว่าง 'ขณะใช้งาน' หรือ 'ขณะจัดเก็บ'
- FHE รักษาข้อมูลให้อยู่ในสภาพเข้ารหัสตลอดทั้งวงจรชีวิต จึงแก้จุดอ่อนเหล่านี้ได้จากรากฐาน
นิยามของการประมวลผลที่เป็นส่วนตัวอย่างสมบูรณ์
- สภาพแวดล้อมในอุดมคติคือข้อมูลยังคง ถูกเข้ารหัส ทั้งตอนจัดเก็บ ตอนส่งผ่าน และตอนใช้งาน (คำนวณ)
- ตัวอย่างเช่น เซิร์ฟเวอร์จะไม่เห็นคำถามในรูป plaintext เลย แต่รับคำถามที่เข้ารหัสและส่งกลับเพียงผลลัพธ์ที่เข้ารหัส
- มีเพียงผู้ใช้เท่านั้นที่สามารถถอดรหัสผลลัพธ์นั้นได้
วิธีทำงานของ FHE: โครงสร้างและแนวคิดทางคณิตศาสตร์
- คำว่า "homomorphic" อาศัยการแปลงทางคณิตศาสตร์ที่คงโครงสร้างเดิมไว้ (เช่น คล้ายกับ Fourier transform)
- FHE แปลงระหว่างพื้นที่ plaintext และพื้นที่ ciphertext แบบสองทาง ทำให้ เมื่อถอดรหัสผลของการคำนวณบน ciphertext แล้ว จะได้ผลลัพธ์เดียวกับการคำนวณบน plaintext
- การแปลงนี้ส่วนใหญ่อาศัย การเข้ารหัสแบบ lattice-based และ LWE (Learning With Errors)
- การเข้ารหัสแบบ lattice-based เป็นปัญหาเวกเตอร์ในปริภูมิที่มีมิติสูงมาก ซึ่งเชื่อกันว่าแม้แต่คอมพิวเตอร์ควอนตัมก็ยังแก้ได้ยาก (ทนทานต่อควอนตัม)
- LWE คือปัญหาการย้อนกลับระบบเชิงเส้นที่มี noise ปนอยู่ ซึ่งในทางปฏิบัติถือว่าถอดรหัสไม่ได้
การจัดการ noise และ bootstrapping
- ใน FHE เมื่อคำนวณซ้ำๆ noise (สัญญาณรบกวน) ภายใน ciphertext จะเพิ่มขึ้น
- ในการบวก noise จะเพิ่มแบบเชิงเส้น ส่วนในการคูณจะเพิ่มแบบทวีคูณ จนสุดท้ายอาจทำให้ถอดรหัสไม่ได้
- เทคโนโลยีหลักที่ใช้แก้ปัญหานี้คือ bootstrapping ซึ่งเป็นเทคนิครีเซ็ตระดับ noise ให้กลับมาอยู่ในระดับที่จัดการได้ โดยการเข้ารหัส ciphertext ใหม่ด้วย 'public key ชุดใหม่'
- กระบวนการนี้เป็นคอขวดด้านประสิทธิภาพของระบบ FHE แต่ก็กำลังได้รับการปรับปรุงอย่างรวดเร็วในทุกปี
องค์ประกอบสำคัญเพิ่มเติมของ FHE
- relinearization: กระบวนการแก้ปัญหาที่หลังการคูณแล้วลำดับของคีย์เพิ่มเป็นกำลังสอง ให้กลับมาเป็นเชิงเส้นอีกครั้ง
- modulus switching: เทคนิคการลด modulus ของ ciphertext เพื่อจัดการ noise
นอกจากนี้ยังมีเทคนิคอีกหลากหลายที่ถูกนำเสนออย่างต่อเนื่องตามพัฒนาการของอัลกอริทึม
การจำแนกระบบ Homomorphic Encryption (HE) และตัวอย่าง Python
- Partial HE: รองรับเพียงการคำนวณชนิดเดียว (เช่น การเข้ารหัสของ Paillier รองรับเฉพาะการบวก)
- Somewhat HE: รองรับทั้งการบวกและการคูณ แต่จำกัดจำนวนครั้งของการคูณซ้ำ
- FHE: รองรับทั้งการบวกและการคูณได้ไม่จำกัด รับประกันความเป็น Turing complete
สามารถทำความเข้าใจ partial homomorphism ได้อย่างเป็นรูปธรรมผ่านตัวอย่าง Paillier cryptosystem ที่เขียนด้วย Python
ประวัติการพัฒนา FHE และ "กฎของมัวร์สำหรับ FHE"
- 1978: แนวคิด "privacy homomorphism" ปรากฏขึ้นเป็นครั้งแรก
- 2009: Craig Gentry ทำ FHE สำเร็จเป็นครั้งแรก (วิทยานิพนธ์ปริญญาเอก)
- 2011: มี implementation แรก ใช้เวลา 30 นาทีต่อบิต (ช้ามาก)
- หลังปี 2013: ลดเวลา bootstrapping ลงมาถึงระดับไม่กี่ ms
- 2017: เริ่มรองรับการประมาณค่าเลขทศนิยมแบบลอยตัว เช่น CKKS และถูกนำไปใช้กับ ML/AI อย่างจริงจัง
อัลกอริทึม FHE พัฒนาขึ้น 8 เท่าทุกปีนับจากปี 2011 ทำให้จากเดิมที่มี overhead ระดับ 10¹⁰ เท่า ลดลงมาอยู่ที่ราว 10³~10⁴ เท่าในปัจจุบัน
งานวิจัยล่าสุดลดทั้ง throughput ของการคูณใน FHE ลงได้ 1,000 เท่า และลด latency ได้ 10 เท่า อีกทั้งหากผสานกับการเร่งความเร็วด้วยฮาร์ดแวร์ ก็ยังมีโอกาสเพิ่มความเร็วได้อีกมากกว่า 1,000 เท่า
อนาคตที่การเข้ารหัสกลายเป็นค่าเริ่มต้น
- เหตุข้อมูลรั่วไหลขนาดใหญ่เป็นความจริงที่หลีกเลี่ยงได้ยาก
- หากใช้ FHE แล้ว เซิร์ฟเวอร์สามารถคำนวณบนข้อมูลที่เข้ารหัสได้โดยไม่ต้องมีคีย์ถอดรหัส ก็จะกลายเป็นมาตรฐานใหม่ของการคุ้มครองความเป็นส่วนตัว
- แม้ตอนนี้ยังไม่ได้ใช้งานจริงอย่างสมบูรณ์ในทุกด้าน แต่กำลังพัฒนาเร็วอย่างน่าทึ่งในทุกปี
- เมื่อความต้องการด้านความเป็นส่วนตัวของผู้ใช้มาบรรจบกับกฎระเบียบที่เข้มงวดขึ้น ในที่สุด FHE ก็น่าจะกลายเป็นมาตรฐานของคลาวด์คอมพิวติงส่วนใหญ่
- การประมวลผลบนอินเทอร์เน็ตในอนาคตจะพัฒนาไปสู่สภาพที่ ถูกเข้ารหัสอยู่เสมอ
ทศวรรษ 2010: HTTPS คือค่าเริ่มต้น
ต่อจากนี้: คาดว่าจะเข้าสู่ยุคที่ FHE คือค่าเริ่มต้น
เอกสารอ้างอิงและแหล่งข้อมูลเพิ่มเติม
- FHE Reference Library: รวมเอกสารวิชาการอย่างครอบคลุม
- วิทยานิพนธ์ปริญญาเอกปี 2009 ของ Craig Gentry: จุดเริ่มต้นของ FHE
- Vitalik Buterin: บทวิเคราะห์เชิงลึกเกี่ยวกับ FHE
- ชุมชน: FHE.org (ศูนย์กลางสำหรับนักพัฒนา)
- GitHub: awesome-he: รวมโปรเจกต์เกี่ยวกับ homomorphic encryption
1 ความคิดเห็น
ความเห็นจาก Hacker News
ขอพูดโดยตั้งต้นจากจุดยืนว่าชอบ FHE และ cryptography มาก FHE เร็วขึ้นเรื่อย ๆ ก็จริง แต่ตราบใดที่ยังต้องพึ่ง bootstrapping ก็ไม่มีทางตามความเร็วการประมวลผลบน plaintext ได้ ทราบกันว่าค่าโอเวอร์เฮดจาก bootstrapping ระดับราว 1000 เท่าขึ้นไปเป็นสิ่งที่หลีกเลี่ยงไม่ได้โดยพื้นฐาน และเมื่อเริ่มตระหนักว่าทำให้เร็วกว่านี้ไม่ได้ ก็เริ่มมีการพูดถึง hardware acceleration ขึ้นมา แต่ในยุคที่พลังประมวลผลแทบทั้งหมดถูกเทไปที่ LLM แบบนี้ก็ไม่ใช่เรื่องง่าย ถ้าคิดดูว่าต้นทุนต่อโทเค็นจะกระโดดขึ้นกี่เท่าเมื่อคำนวณด้วย FHE ก็แทบไม่มีทางเป็นจริงได้ เว้นแต่จะไม่เกิน 1000 เท่ามากนัก หากเป้าหมายคือการปกป้องข้อมูลส่วนบุคคล แนวทาง confidential computing คือทางเลือกเดียวที่ใช้งานได้จริงในตอนนี้ แม้จะไม่ชอบที่ต้องเชื่อถือฮาร์ดแวร์ แต่นั่นคือสิ่งที่ดีที่สุดที่เรามี
มีเหตุผลที่ลึกกว่านั้นจริง ๆ ว่าทำไม FHE ถึงใช้กับการคำนวณแบบ arbitrary ได้ยาก นั่นคือการคำนวณบางประเภทมีความซับซ้อนบน ciphertext พุ่งสูงกว่าบน plaintext อย่างผิดปกติ กรณีค้นหาในฐานข้อมูล บน plaintext เป็น O(log n) แต่ถ้าค้นหาด้วยคีย์ที่เข้ารหัสแล้วจะกลายเป็น O(n) ดังนั้น Google Search แบบ fully homomorphic จึงแทบเป็นไปไม่ได้โดยพื้นฐาน แต่การทำ DNN inference แบบ fully homomorphic อาจต่างออกไป
ต่อให้ไม่มี bootstrapping FHE ก็ไม่มีทางเร็วเท่าการคำนวณบน plaintext ได้อยู่ดี ciphertext มีขนาดใหญ่กว่า plaintext ราว 1000 เท่า หมายความว่าต้องใช้ทั้งแบนด์วิดท์หน่วยความจำและปริมาณการคำนวณมากกว่ามาก ช่องว่างนี้ปิดไม่ได้
ลองคิดดูว่าต่อให้ต้นทุนการคำนวณพุ่งขึ้น 1000 เท่า ก็อาจยังมีกลุ่มความต้องการเฉพาะที่อยากได้ privacy ที่พิสูจน์ได้จริง แม้ตลาดจะไม่ใหญ่เท่า Dropbox แต่ก็น่าจะมีอยู่พอสมควร
ย้อนนึกถึงสมัยก่อนที่ทุกอย่างเป็น PCIE expansion card ทั้งนั้น GPU ก็เป็นแบบนั้น และยังมี accelerator เฉพาะทางอย่าง math coprocessor แยกต่างหาก ทุกวันนี้มันถูกรวมเข้ากับฮาร์ดแวร์อเนกประสงค์เลยถูกกว่าและสะดวกกว่า แต่ก็ทำได้ไม่ดีเท่าซิลิคอนที่ออกแบบมาเฉพาะหน้าที่ จึงมีคนเสนอว่าควรใช้การ์ดเฉพาะสำหรับ AI/ML แยกจากแนวทางที่อิง GPU แม้สถาปัตยกรรมจะทับซ้อนกันบางส่วน แต่การ์ด AI ที่อิง GPU ก็เหมือนยอมเสียเปรียบในหลายด้าน ตัวเร่ง AI ที่แท้จริงน่าจะเป็นฮาร์ดแวร์เฉพาะทางที่ใส่ในซ็อกเก็ต SXM รุ่นใหม่ แต่ซ็อกเก็ต SXM มีเฉพาะในเซิร์ฟเวอร์และราคาก็ไม่เบา
ยอมรับว่ากระแส LLM มาแรง แต่ก็สงสัยว่าจริง ๆ แล้วจะไม่มี use case อื่นให้ FHE เลยหรือ เช่น อาจโฮสต์อัลกอริทึมการเทรดที่ไม่ต้องการความเร็วสูงมากไว้บนเซิร์ฟเวอร์ด้วย FHE เพื่อรับประกันความปลอดภัยก็ได้
เหตุผลที่ FHE สำคัญคือ ปัจจุบันบริษัทต่าง ๆ บางครั้งถูกกดดันจากรัฐบาลให้ต้องทำลายการเข้ารหัสของเป้าหมายบางราย FHE ช่วยให้บริษัทพูดได้อย่างเปิดเผยว่า "เราไม่มีทางเห็น plaintext ได้เลย" ในบทบาทผู้ให้บริการเครือข่ายนั้นพอทำได้บางส่วนผ่าน E2E encryption เป็นต้น แต่เมื่อถึงขั้นต้องประมวลผลข้อมูลในสถานะ plaintext ก็ยังทำไม่ได้ ความเป็นส่วนตัวเป็นสิทธิมนุษยชนขั้นพื้นฐาน และอำนาจของรัฐควรมีผลอย่างจำกัดมากต่อกิจกรรมเชิงประชาธิปไตย เช่น การลงคะแนน ศิลปะ สื่อ และการแสดงออก
ต่อให้ FHE ทำ arbitrary computation ได้ บริการส่วนใหญ่ก็มีคุณค่าเพราะให้ข้อมูลบางอย่างแก่ผู้ใช้ ถ้า Google จะรับประกันความปลอดภัยต่อ query ของฉัน ก็ต้องเข้ารหัสดัชนีการค้นหาทั้งหมด ซึ่งในทางปฏิบัติเป็นไปไม่ได้ และในเชิงธุรกิจก็มองว่าแทบไม่มีแรงจูงใจให้รับบริการแบบ FHE นอกจากในงานที่ต้องการความเชื่อถือสูงและมีความเสี่ยงสูงเพียงไม่กี่ด้าน
เท่าที่รู้ เข้ารหัสเฉพาะข้อมูลที่อ่อนไหวก็พอได้ (เช่น ข้อมูลธุรกรรมธนาคารของฉัน) ตัวฟังก์ชันที่จะใช้คำนวณไม่จำเป็นต้องเข้ารหัส แค่เอาไปใช้ร่วมกับข้อมูลสาธารณะได้ก็พอ
ท้ายที่สุดแล้ว สำหรับบริษัทใหญ่ แหล่งรายได้มักมาจากการต้องมองเห็นข้อมูลหรือ query ของผู้ใช้โดยตรง จึงไม่มีแรงจูงใจให้เอา FHE มาใช้จนเป็นนิสัย ในภาคการเงินอย่างธนาคารอาจดูเข้าท่า แต่ด้านอื่นจะถูกนำมาใช้เมื่อไรยังไม่ชัด
เรื่องแรงจูงใจนั้นจริง แต่ส่วนแรกไม่เหมือนกัน การ lookup แบบ private กับฐานข้อมูล plaintext นั้นทำได้มาหลายปีแล้ว เพียงแต่ต้อง preprocess ฐานข้อมูล plaintext ล่วงหน้าแบบค่อนข้างซับซ้อน หรือในกรณีแย่ที่สุดก็ต้องสแกนทั้งฐานข้อมูลแบบเชิงเส้น
มีการยก spiralwiki.com เป็นตัวอย่าง implementation ของ search engine แบบ FHE ที่เป็นส่วนตัวอย่างสมบูรณ์ โดยเซิร์ฟเวอร์จะไม่มีทางรู้เลยว่าผู้ใช้กำลังอ่านบทความ Wikipedia ใด spiralwiki.com
ใน "มุมของผู้ใช้" อาจมีคนยอมจ่ายเพื่อใช้บริการที่ปกป้องข้อมูลได้สมบูรณ์แบบแบบ FHE แต่ในความเป็นจริงมันจะแพงมากและจำนวนผู้สมัครก็น่าจะน้อยมาก ถ้าคิดจากสมมติฐานว่าต้นทุนคอมพิวต์สูงขึ้นหลายสิบเท่าจากปัจจุบัน ต่อให้บริการแทน Google ที่เน้น privacy จะตั้งราคาได้ที่ปีละ $100 ก็คงดึงผู้ใช้ได้ไม่มาก ยิ่งต้นทุนสูงขึ้น ผู้สมัครก็ยิ่งลดลง ยังมีทางเลือกอย่าง Tor ที่แม้ไม่สมบูรณ์แต่ให้การปกป้องได้มากพอสมควรฟรี ๆ ไม่ใช่ว่า HE (homomorphic encryption) ไม่มีประโยชน์ แต่มีเพียงคนส่วนน้อยมากที่จะยอมรับต้นทุนเพื่อใช้มัน
มีการพูดถึงความเป็นไปได้ที่อินเทอร์เน็ตจะเปลี่ยนจาก "ค่าเริ่มต้นคือการเฝ้าระวัง" ไปเป็น "ค่าเริ่มต้นคือความเป็นส่วนตัว" ตัวฉันเองก็เผยแพร่เทคโนโลยี privacy มานาน เช่น การสร้าง digital signature แต่ก็ต้องมองความจริงว่า Hacker News หรือ Facebook ต่างถือครองตัวตนของผู้ใช้เอาไว้ทั้งหมด เพราะมันง่ายและทำเงินได้ FHE เองก็เป็นเทคโนโลยีประเภท "คนต้องการ แต่ในทางปฏิบัติไม่แพร่หลายอย่างรวดเร็ว" เนื่องจากภาระด้านการดำเนินงานและความซับซ้อนทำให้ในกรณีส่วนใหญ่ วิธีเดิมก็ถือว่าใช้งานได้ดีพอแล้ว
เวลาติดอะไรอย่าง digital signature ไว้ท้ายอีเมล ก็ได้ปฏิกิริยาแค่ประมาณว่า "นั่นอะไรน่ะ?" เลยสงสัยว่ามีใครเคยมีประสบการณ์โน้มน้าวให้ผู้ใช้ทั่วไปเข้าร่วมกับการเข้ารหัสฝั่งไคลเอนต์ได้จริงไหม
มีความเห็นว่าเมื่อ FHE รวมกับ AI แล้ว AI อาจช่วยแบกรับภาระความซับซ้อนบางส่วน จนกลายเป็นการจับคู่ที่อาจเป็น killer combo และใช้งานกันอย่างแพร่หลายจริงก็ได้
มองตามความเป็นจริงแล้ว บริษัทต่าง ๆ คงไม่มีเหตุผลจะใช้โซลูชันแบบบริการ FHE ที่ต้องใช้คอมพิวต์มากขึ้น 1,000,000 เท่า ดีบักยากขึ้น และยังวิเคราะห์รูปแบบการใช้งานไม่ได้อีก
การเริ่มเล่าเรื่องด้วยตัวอย่าง Google อาจทำให้เข้าใจผิดได้ ปกติพอพูดว่า "Google" คนจะนึกถึง "เว็บเสิร์ช" แต่ FHE ที่อธิบายในบทความอาจไม่เข้ากับบริบทของบริการค้นหา เพราะอินพุตทั้งหมดต้องถูกเข้ารหัสด้วยคีย์เดียวกัน ดัชนีค้นหาของ Google มีขนาดหลาย TB และแทบเป็นไปไม่ได้ที่จะเข้ารหัสทั้งหมดนั้นด้วยคีย์เฉพาะเดียว กล่าวคือ FHE จะมีประโยชน์ก็ต่อเมื่อผู้ใช้ควบคุมอินพุตทั้งหมดเอง การอ้างถึง Google จึงทำให้สับสน
ในกรณีอย่าง CallerID ของ Apple ดูเหมือนไม่จำเป็นต้องเข้ารหัสฐานข้อมูลทั้งหมดแยกตามผู้ใช้ก็ได้ งานวิจัย homomorphic encryption ของ Apple / การค้นหาแบบคุ้มครองความเป็นส่วนตัวของ Apple
บริการแบบ homomorphic encryption ไม่จำเป็นต้องรู้คีย์เข้ารหัสล่วงหน้าอยู่แล้ว นั่นคือแก่นสำคัญ มีการยกตัวอย่างการเข้ารหัสแบบง่ายมากที่สามารถนำ ciphertext มาบวกกันได้แม้ไม่ระบุคีย์ล่วงหน้า และถ้ารองรับการเข้ารหัสที่แข็งแรงกว่านั้นพร้อมการคำนวณที่ซับซ้อนขึ้น ก็จะสร้างฟังก์ชันได้หลากหลายมาก
พอพูดถึง Google ก็ไม่ได้มีแค่เสิร์ช ยังมี Gmail, Google Docs และบริการที่เกี่ยวกับข้อมูลส่วนบุคคลอีกมาก คนที่นึกถึงแค่เสิร์ชน่าจะไม่ได้อ่านบทความที่เกี่ยวข้องตั้งแต่แรก
คิดว่า FHE คงยังไม่ถูกนำไปใช้กับการประมวลผลทั่วไปหรือบริการอินเทอร์เน็ตแบบกว้าง ๆ ได้ทันที อย่างน้อยคงต้องรอให้กฎของมัวร์เดินต่อไปอีกหลายเจเนอเรชัน แต่มีบางด้านที่ FHE เริ่มฉายแสงแล้ว คือสมาร์ตคอนแทรกต์ การเงิน และการแพทย์ ซึ่งแม้ความซับซ้อนไม่สูงมาก แต่ต้องการความปลอดภัยและความน่าเชื่อถืออย่างมาก มองว่าช่วงหลังด้วย Moore's law และการปรับแต่งซอฟต์แวร์ เส้นโค้งเริ่มหันไปสู่ฝั่งที่ใช้งานได้จริงแล้ว โดยยก งานด้านฮาร์ดแวร์/Devtools ของ Zama เป็นตัวอย่าง
มีการพัฒนา E2EE git ขึ้นมาแล้ว ฉันเคยถามคนสร้างว่าจะแก้ข้อกำหนดอย่าง protected branch หรือการป้องกัน force push บนเซิร์ฟเวอร์ได้ไหม แต่ถ้าไคลเอนต์เป็นอันตรายจริงก็ไม่มีทางรับมือที่ดีนัก เลยสงสัยว่าวันหนึ่งมันจะพัฒนาไปเป็น E2EE Github ได้ไหม ลิงก์ Hacker News ที่เกี่ยวข้อง
เวลาฟังวาทกรรมที่ว่า FHE จะเร็วขึ้นเรื่อย ๆ ก็นึกถึงโจทย์คณิตศาสตร์เก่าเรื่องความเร็วเฉลี่ย เช่น ถ้าวิ่งขึ้นเนิน 1 ไมล์ด้วยความเร็ว 15 ไมล์ต่อชั่วโมง แล้วต้องลงเนิน 1 ไมล์ด้วยความเร็วเท่าไร จึงจะทำให้ความเร็วเฉลี่ยตลอด 2 ไมล์เป็น 30 ไมล์ต่อชั่วโมง อัตราการพัฒนาในอดีตไม่ได้รับประกันความเป็นไปได้ในอนาคต นี่ไม่ใช่ข้อจำกัดทางฟิสิกส์ แต่เป็นข้อจำกัดของอัลกอริทึม
ถ้าทางลงเป็นหน้าผาจะเป็นอย่างไร? ถ้าคิดจาก terminal velocity ของรถสัก 200-300mph ก็อาจคำนวณได้ว่าตกอิสระผ่านระยะ 1 ไมล์ใน 15 วินาทีก็ยังพอเป็นไปได้บนกระดาษ การจะให้ระยะรวม 2 ไมล์มีความเร็วเฉลี่ย 30mph ต้องใช้เวลา 4 นาที ดังนั้นความเร็วช่วงขึ้นเนินก็ต้องปรับให้สอดคล้องกับเวลาที่เหลือ แต่ในโลกจริงมีตัวแปรอีกมากจนทำไม่ได้
ถ้าคำนวณอย่างเคร่งครัด ช่วงลงเนินแค่ทำ 41mph ก็พอให้ความเร็วเฉลี่ยรวมเป็น 30mph ได้ หากสมมติว่าโจทย์มีการปัดตัวเลขหรือมีความคลาดเคลื่อนในการวัดอยู่แล้ว ก็จะได้คำตอบแบบนี้