GnuPG (GNU پرائیویسی گارڈ) پروجیکٹ کے بنیادی ڈویلپر اور تخلیق کار، ورنر کوچ نے LibrePGP پروجیکٹ کی بنیاد رکھی، جس نے OpenPGP معیار کے لیے ایک تازہ ترین متبادل تفصیلات تیار کرنے پر توجہ مرکوز کی۔ یہ کانٹا IETF ورکنگ گروپ کی طرف سے OpenPGP تفصیلات (RFC-4880) میں اگلی اپ ڈیٹ کے لیے منصوبہ بندی کی گئی تبدیلیوں کے جواب میں بنایا گیا تھا اور کوچ نے اسے مطابقت اور حفاظتی نقطہ نظر سے قابل اعتراض سمجھا تھا۔ GnuPG, RNP (Thunderbird's OpenPGP نفاذ) اور Gpg4win پروجیکٹس کے ڈویلپرز جنہوں نے فورک کو سپورٹ کیا تھا ان کو خدشہ ہے کہ منصوبہ بند تبدیلیاں OpenPGP پر مبنی ایپلی کیشنز کے موجودہ نفاذ کے لیے نقصان دہ ہوں گی، جن کے صارفین توقع کرتے ہیں کہ تصریح طویل مدت میں مستحکم رہے گی اور ایسا نہیں ہے۔ مطابقت کو توڑنے والی تبدیلیوں کو برداشت کرنے کے لیے تیار ہیں۔
LibrePGP مفید اصلاحات کو شامل کرتا ہے جو حالیہ برسوں میں OpenPGP تفصیلات کے مستقبل کے ورژن کے لیے تیار کی گئی ہیں، لیکن ان تبدیلیوں سے گریز کرتی ہیں جو مطابقت پر منفی اثر ڈالتی ہیں۔ مثال کے طور پر، موجودہ RFC-4880 معیار کے مقابلے، LibrePGP نے درج ذیل خصوصیات کو اپنایا ہے:
- کیمیلیا انکرپشن الگورتھم سپورٹ (RFC-5581)،
- OpenPGP (RFC-6637) کے لیے ECC (Elliptic Curve Cryptography) ایکسٹینشنز۔
- SHA2-256 ہیشز کے لیے لازمی سپورٹ (SHA-1 اور MD5 کی درجہ بندی کی گئی ہے جیسا کہ تجویز کردہ نہیں ہے، اور انٹیگریٹی ورژننگ کے بغیر ڈیٹا کو ڈکرپٹ کرنے کی صلاحیت کو مکمل طور پر متروک قرار دیا گیا ہے)۔
- فنگر پرنٹ کے سائز کو 256 بٹس تک بڑھانا۔
- EdDSA ڈیجیٹل دستخطی اسکیم اور BrainpoolP256r1، BrainpoolP384r1، BrainpoolP512r1، Ed25519، Curve25519، Ed488 اور X448 بیضوی وکر دستخطی اسکیموں کو سپورٹ کرتا ہے۔
- CRYSTALS-Kyber الگورتھم کے لیے سپورٹ، جو کوانٹم کمپیوٹرز پر انتخاب کے لیے مزاحم ہے۔
- OCB (آفسیٹ کوڈ بک موڈ) تصدیق شدہ انکرپشن موڈز کے لیے سپورٹ۔
- میٹا ڈیٹا کے تحفظ کے ساتھ ڈیجیٹل دستخطی فارمیٹ کے پانچویں ورژن کا نفاذ۔
- ڈیجیٹل دستخطوں کے ساتھ توسیع شدہ ذیلی پیکجز کے لیے معاونت۔
نئی OpenPGP تفصیلات کی تنقید کے اہم عناصر:
- IETF ورکنگ گروپ نے تفصیلات کو بتدریج بتدریج اپ ڈیٹ کرنے کے بجائے، معیار کو دوبارہ ایجاد کرنے اور اس میں اہم تبدیلیاں کرنے کی کوشش کی جس سے انٹرآپریبلٹی ٹوٹ جائے گی۔
- سیمیٹرک GCM (گیلوئس/کاؤنٹر موڈ) انکرپشن موڈ کے لیے سپورٹ مسلط کرنا، جس کو درست طریقے سے نافذ کرنا مشکل ہے، OCB (آفسیٹ کوڈ بک موڈ) کو نظر انداز کرتے ہوئے، جس کے پیٹنٹ کئی سال پہلے ختم ہو چکے ہیں۔
- ٹریفک تجزیہ سے بچانے کے لیے بے ترتیب پیڈنگ کے ساتھ اختیاری پیکجوں کو شامل کرنا۔ LibrePGP کے تخلیق کاروں کے مطابق، ناقابل تصدیق ابتدائی رینڈم فلنگ کے ساتھ ایسے پیکٹ چھپے ہوئے ڈیٹا ٹرانسمیشن چینلز بنانے اور ڈیٹا لیک کی روک تھام کے نظام کو بائی پاس کرنے کے لیے استعمال ہونے کا خطرہ لاحق ہیں۔ پہلے، پیڈنگ کو شامل کرنے کے خیال کو خفیہ کاری کی سطح کے مسئلے کی بجائے ایپلیکیشن لیول کا مسئلہ ہونے کی وجہ سے مسترد کر دیا گیا تھا۔
- RFC-6637 میں پہلے سے بیان کردہ اور PGP اور GnuPG میں نافذ کردہ آپشن کو استعمال کرنے کے بجائے، ترمیم شدہ ECDH انکرپشن سکیم (OID فارمیٹ میں تبدیلی) کا استعمال۔
- کچھ عملی خصوصیات کو ہٹانا، جیسے کلاسک کلیدی تنسیخ کا طریقہ، MIME ڈیٹا کو نشان زد کرنے کے لیے "m" جھنڈا، اور متن کو بائنری ڈیٹا سے الگ کرنے کے لیے "t" جھنڈا ("t" پرچم کو "u" پرچم سے بدل دیا گیا تھا۔ انکوڈ شدہ متن کے لیے UTF-8)۔
- دستخط شدہ فائل کے میٹا ڈیٹا کے تحفظ کو نئے دستخطی فارمیٹ میں شامل کرنے سے انکار (مثال کے طور پر، آپ دستخط کی خلاف ورزی کیے بغیر فائل کا نام تبدیل کر سکتے ہیں)۔
- دیئے گئے سابقہ کے ساتھ تصادم کے حملوں سے تحفظ کو بڑھانے کے لیے دستخطوں (نمک والے دستخط) میں "نمک" شامل کرنے کا مشکوک امکان۔ نمکین قیمت کو دستخط میں 32 بائٹس ڈیٹا لے جانے کے لیے غیر معذور خفیہ چینل کے طور پر استعمال کیا جا سکتا ہے۔
- طویل مدتی ڈیٹا سٹوریج کی ضروریات کو نظر انداز کرتے ہوئے، آن لائن کمیونیکیشن کے بنیادی استعمال کی طرف معیار کی تبدیلی۔
اوپن پی جی پی کے حامی پہلے ہی تنقید پر تنقید شائع کر چکے ہیں۔ نتیجے کے طور پر، اگر کوئی سمجھوتہ نہیں پایا جا سکتا ہے، تو تقسیم OpenPGP/LibrePGP نفاذ میں بڑھتی ہوئی عدم مطابقتوں کا باعث بن سکتی ہے۔ جزوی طور پر اس مسئلے کو حل کرنے کے لیے، OpenPGP ڈویلپرز نے دستخطی فارمیٹ کے پانچویں ورژن کو LibrePGP کے ساتھ ہم آہنگ کیا اور چھٹے ورژن پر کام کرنے کے لیے آگے بڑھا۔
ماخذ: opennet.ru
