একটা scenario চিন্তা করুন। আপনার ব্যাংক অ্যাপে login করলেন। পাসওয়ার্ডটা HTTPS (Hypertext Transfer Protocol Secure) দিয়ে সুরক্ষিত হয়ে গেল। এই সুরক্ষার পেছনে কাজ করছে RSA (Rivest-Shamir-Adleman) বা ECC (Elliptic Curve Cryptography) নামের public-key cryptography। আজকের কম্পিউটার দিয়ে এই encryption ভাঙতে হাজার বছর লেগে যাবে। পুরো পৃথিবীর সব supercomputer মিলেও পারবে না।
কিন্তু quantum computer এলেই হিসাবটা বদলে যায়।
Quantum computer এ Shor এর algorithm চালালে RSA, ECC, সব কিছু মুহূর্তেই ভেঙে যেতে পারে। এই হুমকি থেকে বাঁচতেই cryptography জগতে এখন চলছে post-quantum cryptography (PQC) নিয়ে প্রস্তুতি। আর Java এই প্রস্তুতিতে এগিয়ে আছে। শুধু নতুন JDK (Java Development Kit) না, Oracle এখন পুরনো LTS (Long-Term Support) release গুলোতেও PQC আনছে। JDK ২৫, ২১, ১৭, ১১, এমনকি ৮ পর্যন্ত।
Quantum computer হুমকিটা আসলে কী
আজকের internet এর পুরো নিরাপত্তা ব্যবস্থা দাঁড়িয়ে আছে দুই ধরনের কাজের উপর। একটা হলো encryption, যেটা data কে অন্যদের পড়তে না দেয়। আরেকটা হলো digital signature, যেটা প্রমাণ করে, data টা আসল এবং কারো দ্বারা বদলানো হয়নি।
এই দুই কাজই করে public-key algorithm গুলো। RSA, ECC, এগুলো। এদের শক্তির উৎস হলো, reverse করা অসম্ভব রকম কঠিন। যেমন, দুটো বড় prime number গুণ করা সহজ, কিন্তু গুণফল দেখে prime দুটো বের করা প্রায় অসম্ভব। এই অসম্ভবতাই আজকের internet কে নিরাপদ রাখছে।
Quantum computer সেই অসম্ভবতাকে সম্ভব করে দিতে পারে। শুধু ভবিষ্যতের হুমকি নয়, এখনই একটা সমস্যা আছে। Cyber criminal রা এখন যে data চুরি করছে, সেটা সংগ্রহ করে রাখছে। ভবিষ্যতে quantum computer হাতে পেলে একসাথে সব খুলে ফেলবে। এই পদ্ধতির নাম আছে, harvest now, decrypt later।
PQC মানে কী
PQC এমন algorithm, যেটা quantum computer দিয়েও ভাঙা যায় না। এই algorithm গুলো বানানো হয়েছে এমন math দিয়ে, যেটা quantum attack সহ্য করতে পারে।
২০২৪ সালের August এ NIST (National Institute of Standards and Technology) দুটো algorithm standard করেছে। একটা হলো ML-KEM (Module-Lattice Key Encapsulation Mechanism), encryption এর জন্য। আরেকটা হলো ML-DSA (Module-Lattice Digital Signature Algorithm), digital signature এর জন্য। ML-KEM এনক্রিপ্ট করা data রক্ষা করে। ML-DSA প্রমাণ করে, message টা কারো দ্বারা বদলানো হয়নি। মানে, public-key cryptography এর দুইটা কাজই cover হয়ে গেল।
Java তে কখন কী আসছে
Java টিম কিন্তু আজ থেকে শুরু করেনি। পথচলা শুরু হয়েছিল কয়েক বছর আগে। ধাপগুলো দেখলে টাইমলাইনটা পরিষ্কার হয়।
প্রথম ধাপ, JDK ২১। ২০২৩ সালের September এ JDK ২১ এ আসে KEM (Key Encapsulation Mechanism) API। JEP (JDK Enhancement Proposal) 452 এর মাধ্যমে। এটা হলো ভবিষ্যতের key establishment algorithm গুলোর ভিত্তি। তখনো নির্দিষ্ট কোনো post-quantum design বাছাই করা হয়নি, শুধু foundation টা তৈরি হয়ে গেল।
দ্বিতীয় ধাপ, JDK ২৪। ২০২৫ সালের March এ JDK ২৪ এ দুটো algorithm ই যোগ হলো। ML-KEM এলো JEP 496 দিয়ে। ML-DSA এলো JEP 497 দিয়ে। মানে, এই মুহূর্তে JDK ২৪ তে post-quantum secure application বানানোর সব building block আছে।
তৃতীয় ধাপ, TLS (Transport Layer Security)। বাস্তবে বেশিরভাগ application নিজে algorithm use করে না। Java এর TLS implementation ই network connection secure করে। তাই PQC কে সত্যিকারের কাজে লাগাতে হলে TLS এও support দরকার। সেটা আসছে JDK ২৭ এ। JEP 527 দিয়ে hybrid post-quantum key exchange আনা হচ্ছে TLS 1.3 এর জন্য। JDK ২৭ এর GA (General Availability) সেপ্টেম্বর ২০২৬ এ।
পুরনো LTS release গুলোর খবর
এখানেই সবচেয়ে মজার অংশ। অনেক organization এখনো JDK ৮ বা ১১ তে production application চালায়। নতুন JDK এ upgrade করা মানে বিশাল কাজ। Oracle বুঝেছে, এতেই সবচেয়ে বেশি বাধা আসে। তাই এখন পুরনো LTS release গুলোতেও PQC পৌঁছে দেওয়ার পরিকল্পনা ঘোষণা করেছে।
টাইমলাইনটা এমন:
- JDK ২৫: অক্টোবর ২০২৬ এর Critical Patch Update (CPU) এ JDK ২৭ এর সমান PQC capability পাবে
- JDK ২১ আর ১৭: ২০২৭ এর প্রথমার্ধে
- JDK ১১ আর ৮: ২০২৭ এর দ্বিতীয়ার্ধে
একটা উদাহরণ দিলে পরিষ্কার হবে। ধরুন, আপনার company এখনো JDK ১৭ তে আছে। ২০২৭ এর প্রথমার্ধে update এলেই ওখানে PQC enabled TLS ব্যবহার করতে পারবেন। পুরো application নতুন করে লেখা লাগবে না। এই backport কাজটা ইতিমধ্যে শুরু হয়ে গেছে। KEM API টা Java SE 17 এ Maintenance Release 1 এর মাধ্যমে ঢুকিয়ে দেওয়া হয়েছে।
আপনার application এ কী করতে হবে
ভালো খবর হলো, বেশিরভাগ application এ বড় code change লাগবে না। যেসব application Java এর TLS stack use করে, তাদের জন্য update আর configuration ই যথেষ্ট। মানে, প্ল্যাটফর্ম আপডেট করলেন, configuration ঠিক করলেন, ব্যস।
কিন্তু মনে রাখতে হবে, PQC ready মানে শুধু feature পাওয়া না। Platform, protocol, certificate, infrastructure, সবকিছু মিলে একসাথে evolve করতে হবে। Oracle ও সেটাই বলছে। প্ল্যাটফর্ম PQC enable করবে, কিন্তু force করবে না। নিজে configuration করে validate আর test করে নিতে হবে যে, সত্যিই PQC negotiate হচ্ছে কিনা।
আরেকটা জিনিস মনে রাখা জরুরি। Security একটা continuous process। একদিনে শেষ হয় না। নতুন threat আসবে, নতুন technology আসবে। তাই এখন থেকেই Java crypto roadmap ফলো করা শুরু করা ভালো। Oracle এর Crypto Roadmap আপডেট হয় নিয়মিত। (লিংক)
বাংলাদেশের Java developer দের জন্য মানে কী
বাংলাদেশের অনেক company তে এখনো JDK ৮ বা ১১ এ production application চলছে। এই খবর তাদের জন্যই দারুণ। কারণ পুরো system upgrade করার pressure ছাড়াই, শুধু update আর configuration দিয়ে PQC ready হওয়া যাবে। যারা company change করে নতুন JDK তে যাওয়ার ভয় পান, তাদের জন্য এটা একটা সহজ পথ খুলে দিচ্ছে।
আর যারা নতুন project শুরু করছেন, তারা তো JDK ২৪ বা ২৭ নিয়েই শুরু করতে পারেন। সেক্ষেত্রে শুরু থেকেই PQC ready থাকবেন।
শেষ করি একটা প্রশ্ন দিয়ে
আপনার project কোন JDK version এ চলছে? ৮, ১১, ১৭, নাকি ২১? ২০২৭ এর মধ্যে আপনার version টার update আসবে, সেটা ঠিক আছে। কিন্তু production এ PQC সত্যিই কাজ করছে কিনা, সেটা এখন থেকেই test শুরু করা কি ভালো হবে না?
বিস্তারিত পড়তে পারেন Oracle এর অফিসিয়াল blog post এ। (লিংক)
