Khatm
تجريبي · Sandbox
توقيعات جاهزة لعصر الحوسبة الكمية.
تختبر Khatm خوارزمية ML-DSA، خوارزمية التوقيع التي اعتمدها NIST لمقاومة الحواسيب الكمية. الواجهة نفسها والمسار نفسه للموقِّع: يتغيّر مُعامل واحد فقط.
بنية مفاتيح اختبارية بلا قيمة قانونية. يبقى الوضع الكلاسيكي هو الافتراضي.
لماذا التفكير في ذلك من الآن.
يجب أن يبقى التوقيع قابلًا للتحقق ما دام العقد الذي يحميه قائمًا.
- عقود تدوم : يُحفَظ عقد الإيجار أو القرض أو العمل عشر سنوات أو عشرين أو ثلاثين. ويجب أن يصمد توقيعه طوال هذه المدة.
- تهديد معروف : قد يتمكّن حاسوب كمي قوي بما يكفي يومًا ما من تزوير توقيعات RSA وECDSA المستخدمة اليوم.
- معيار منشور : نشر NIST خوارزمية ML-DSA عام 2024 (FIPS 204). وتدعمها صيغتا X.509 وCMS بالفعل (RFC 9881 و9882).
ثلاثة أوضاع، ومُعامل واحد.
اختر الوضع عند إنشاء الطلب. ولا يتغيّر باقي المسار.
كلاسيكي · افتراضي
المسار الحالي، دون تغيير.
- داخل ملف PDF : توقيع PAdES بـ RSA أو ECDSA
- في ملف الأدلة : تقرير الأدلة وevidence.json
- مقروء في Adobe : نعم
- يقاوم الهجمات الكمية المعروفة : لا
هجين · موصى به للاختبار
مقروء في كل مكان اليوم، وقابل للإثبات غدًا.
- داخل ملف PDF : توقيع PAdES الكلاسيكي وحده
- في ملف الأدلة : إضافةً إليه: توقيع ML-DSA منفصل على البايتات نفسها تمامًا
- مقروء في Adobe : نعم، للجزء الكلاسيكي
- يقاوم الهجمات الكمية المعروفة : عبر دليل ML-DSA
ML-DSA · تجريبي
ما بعد الكم بالكامل، ويُتحقَّق منه عبر Khatm.
- داخل ملف PDF : توقيع PAdES بـ ML-DSA
- في ملف الأدلة : تقرير الأدلة وevidence.json
- مقروء في Adobe : ليس بعد
- يقاوم الهجمات الكمية المعروفة : نعم
المتغيّرات ML-DSA-44 و65 (افتراضي) و87. خارج Sandbox يُرفَض ml-dsa وhybrid (422) ولا يُنشأ شيء.
تكاملك لا يتغيّر.
أضف signature_algorithm عند الإنشاء. بعد التوقيع، يحمل كل طلب كتلة verification يقرؤها برنامجك.
يمكن لأي شخص التحقق منه.
لا تستطيع قارئات PDF التحقق من ML-DSA بعد. صفحة «التحقق من مستند» العامة تفعل ذلك: أودِع ملف PDF ودليله، ولا يُحفَظ شيء.
- لم يتغيّر في المستند بايت واحد
- التوقيع يطابق شهادته
- الشهادة ترتبط بجهة معروفة
- دليل ML-DSA يخصّ هذا المستند بعينه
- لا يُعَدّ مستند هجين صالحًا أبدًا دون دليله
تحقّقت أدوات مستقلة من التوقيعات: iText 9.5 وOpenSSL 3.6.
ما لا نَعِد به بعد.
تشفير ما بعد الكم ما زال حديثًا. هذا، بوضوح، ما وصلت إليه المنظومة.
- بلا قيمة قانونية : تعتمد توقيعات ML-DSA في Sandbox على بنية مفاتيح اختبارية. ليست مؤهّلة ولا معتمدة.
- قارئات PDF : لا يتحقق Adobe Acrobat ولا القارئات الأخرى من ML-DSA بعد. يُبقي الوضع الهجين توقيعًا مقروءًا في كل مكان.
- الختم الزمني : ما زالت جهة الختم الزمني توقّع بـ RSA: التاريخ غير محميّ من مهاجم كمي.
- معايير قيد الإعداد : لم تنشر ETSI بعد ملف PAdES خاصًا بـ ML-DSA. تتبع Khatm معيار PAdES baseline وRFC 9881 و9882.
- وحدة غير معتمدة : المكتبة المستخدمة، Bouncy Castle، ليست وحدة تشفير معتمدة وفق FIPS 140.
الخطوات التالية، خطوة بخطوة.
كل خطوة ترفع قيدًا. ولا نَعِد بأي منها في تاريخ محدّد.
- مفاتيح في HSM : مفاتيح ML-DSA تُولَّد وتُحفَظ في وحدة عتادية.
- شهادات معترف بها : جهة تُصدر شهادات ML-DSA مع آلية للإبطال.
- ختم زمني ما بعد الكم : فور توفّر جهة ختم زمني تعمل بـ ML-DSA.
- المعايير والقارئات : ملفات ETSI، ثم دعم قارئات PDF.
أسئلة متكررة.
هل توقيعاتي الحالية مهدّدة؟
ليس اليوم: لا يوجد حاسوب كمي معروف قادر على تزوير توقيع RSA أو ECDSA. المسألة تخصّ المستندات التي يجب أن تبقى قابلة للتحقق سنوات طويلة.
هل يمكنني استخدامه لعقود حقيقية؟
ليس بعد. تعتمد توقيعات ML-DSA في Sandbox على بنية مفاتيح اختبارية وليست لها قيمة قانونية. لمستنداتك الحقيقية، احتفظ بالوضع الكلاسيكي.
أي وضع أختبر؟
الوضع الهجين: يحتفظ ملف PDF بتوقيع كلاسيكي مقروء في كل مكان، ويرافقه دليل ML-DSA في ملف الأدلة.
هل يلاحظ الموقِّع أي فرق؟
لا. يتلقّى البريد نفسه ويوقّع بالطريقة نفسها. وحدها الخوارزمية التي تختم المستند تتغيّر.
لماذا التوقيعات أكبر حجمًا؟
يبلغ حجم توقيع ML-DSA-65 نحو 3.3 كيلوبايت، مقابل 256 بايت لتوقيع RSA-2048. وفي عقد من بضع صفحات، يبقى الفرق ضئيلًا.
كيف أتحقق من توقيع ML-DSA؟
من صفحة «التحقق من مستند» العامة، أو عبر POST /v1/verify. أودِع ملف PDF، ومعه دليل .p7s أو evidence.json إن كان المستند هجينًا.
جرّب ما بعد الكم دون أن تكسر شيئًا.
يبقى الوضع الكلاسيكي هو الافتراضي. لم تُفتح Sandbox ما بعد الكم للجميع بعد: راسلنا ليصلك إشعار وتجرّبها على مستنداتك.
contact@khatm.io