التصميم التقني

هذه الصفحة نظرة تقنية بتركيز على الأمان. هي تشرح الإجراءات وقرارات التصميم وراء Safeparts، وليس تفاصيل الشيفرة.

إذا كنت تبدأ لأول مرة، ابدأ بـ دليل البدء والأمان.

ما هو Safeparts (وما الذي ليس هو)

Safeparts أداة استرداد تعتمد على k من n مبنية على Shamir secret sharing.

أقل من k حصص: الاسترداد غير ممكن.
أي k حصص من نفس المجموعة: الاسترداد ينجح.

Safeparts ليس نظام تخزين. خطة التخزين والتوزيع لديك هي حد الأمان الحقيقي.

تدفق البيانات من البداية للنهاية

Safeparts يضع طبقات مقصودة لتقليل الأخطاء التشغيلية (حصة خاطئة، خطأ كتابة، خلط مجموعات). وإن رغبت، يمكنك إضافة عامل ثانٍ: عبارة مرور.

تدفق التقسيم
------------
بايتات السر
  |
  | (اختياري) حماية بعبارة مرور
  |   - Argon2id(passphrase, salt, parameters) -> مفتاح 32 بايت
  |   - ChaCha20-Poly1305(key, nonce) -> نص مشفّر
  |
  | data_to_split = نص صريح أو نص مشفّر
  |
  | integrity tag = BLAKE3(data_to_split)   (32 بايت)
  | tagged = data_to_split || integrity tag
  |
  | Shamir split(tagged, k, n, set_id) -> n حصص
  |
  | تغليف كل حصة داخل SharePacket ذاتية الوصف
  |
  | ترميز للحفظ/النقل (base64url | base58check | mnemonic)

تدفق الاسترداد
-------------
فك ترميز الحصص -> SharePackets
  |
  | التحقق من تطابق البيانات التعريفية (set_id, k, n, x, crypto params)
  |
  | Shamir combine -> بايتات tagged
  |
  | تقسيم tagged إلى (data_to_split, integrity tag)
  | التحقق: BLAKE3(data_to_split) == integrity tag
  |
  | إذا كانت مشفّرة:
  |   Argon2id(passphrase, salt, parameters) -> key
  |   ChaCha20-Poly1305 decrypt(key, nonce) -> secret
  |
  +-> إخراج بايتات السر

بنية البيانات عند التقسيم

Safeparts يتعامل مع الإدخال كـ مصفوفة بايتات ويقسمه بايتاً ببايت. القيمة التي يتم تقسيمها فعلياً هي:

data_to_split (نص صريح أو نص مشفّر)
يتبعه وسم سلامة BLAKE3 بطول 32 بايت

ليكن طول الحمولة الموسومة L بايت. عند كل موضع بايت i:

تُفسر البايت كحد ثابت لمتعدد حدود من الدرجة k-1 في GF(256).
تُولّد معاملات عشوائية عددها k-1 (متعدد حدود مستقل لكل موضع).
يُقيّم متعدد الحدود عند x = 1..n لإنتاج n بايتات ناتجة.

حمولة كل حصة هي تسلسل قيم y عبر جميع المواضع L، لذلك يكون طول كل حصة مساوياً لطول الحمولة الموسومة. وتخزن الحزمة قيمة x الخاصة بها، مع k وn وset_id، بحيث يمكن إعادة التركيب من أي k حصص وتُستعاد كل بايت على حدة.

تفاصيل المشاركة بالعتبة

Safeparts يستخدم Shamir secret sharing فوق المجال المنتهي GF(256) بشكل byte-wise.

انعكاسات عملية:

يعمل مع أي سر ثنائي: السر مجرد بايتات (ملفات، مفاتيح، عبارات، إلخ).
حد أعلى لعدد الحصص: في GF(256) يوجد 256 عنصر. يحجز Safeparts القيمة x = 0 لإعادة التركيب، لذلك 1 <= n <= 255.
لا تسريب للبنية: أقل من k حصص لا تعطي معلومات مفيدة عن بايتات السر.

لماذا GF(256) بدلاً من مجال أولي كبير

بعض تطبيقات Shamir تمثل السر كعدد كبير mod prime. Safeparts يختار GF(256) لأن التعامل مع البايتات مباشر وفعّال ولا يحتاج قواعد packing إضافية.

المقابل هو حد 255 حصة لكل مجموعة، وهو عادةً أعلى بكثير مما تحتاجه خطط الاسترداد الواقعية.

حزم الحصص والبيانات التعريفية (تقليل الأخطاء)

حصص Safeparts ليست نقاطاً خاماً (x, y) فقط. كل حصة تُغلف داخل حزمة ذاتية الوصف ومُصدَّرة بإصدار حتى:

يصبح خلط حصص من مجموعات مختلفة أصعب بالخطأ.
تستطيع طبقة الفك رفض المدخلات المبتورة/التالفة.
تُحمل إعدادات التشفير (إن وُجدت) مع مجموعة الحصص.

شكل الحزمة (مبسّط):

SharePacket
----------
magic      : "SMN1"
version    : u8
flags      : u8   (مثال: encrypted)
k, n, x    : u8, u8, u8
set_id     : 16 بايت (معرّف عشوائي لمجموعة الحصص)

إذا كانت مشفّرة:
  salt         : 16 بايت
  nonce        : 12 بايت
  argon mem    : u32 (KiB)
  argon time   : u32
  argon par    : u32

payload_len: u32
payload    : bytes   (بيانات الحصة)

ملاحظة أمنية: البيانات التعريفية (مثل k وn وطول الحمولة) ليست سرية. السرية تأتي من المشاركة بالعتبة ومن (اختيارياً) التشفير.

السلامة: لماذا يوجد وسم BLAKE3

Shamir يعطي سرية حتى تكتمل k حصص، لكنه وحده لا يكشف أخطاء المستخدم دائماً. على سبيل المثال، إدخال حصة خاطئة قد ينتج مخرجات “ما” دون أن تعرف أنها خاطئة.

لذلك يضيف Safeparts وسم سلامة بطول 32 بايت:

أثناء التقسيم: حساب BLAKE3(data_to_split) وإلحاقه.
أثناء الاسترداد: إعادة الحساب والمقارنة؛ إن لم يتطابق يفشل الاسترداد.

ماذا يفيد هذا الوسم؟

كشف تلف الحصص (نسخ/لصق خاطئ، تخزين تالف).
كشف خلط مجموعات مختلفة.
التحقق من نص مشفّر مُعاد تركيبه بدون معرفة عبارة المرور.

وماذا ليس هو؟

ليس MAC بمفتاح، ولا يوفر أصالة ضد مهاجم يملك k حصص. (إذا امتلك مهاجم k حصص، فالسرية ضاعت بالفعل.)

لماذا BLAKE3 (وليس SHA-256 مثلاً)

BLAKE3 اختيار مناسب كـ hash حديث وسريع:

سريع على أغلب المعالجات، حتى منخفضة الطاقة.
مناسب للتوازي والتجزئة (incremental).
تصميم محافظ وله سلالة قوية (مبني على BLAKE2).

استخدام SHA-256 ممكن أيضاً كـ checksum بعد الاسترداد. اختيار BLAKE3 هنا بالأساس قرار أداء وملاءمة.

حماية اختيارية بعبارة مرور

Safeparts يستطيع تشفير السر قبل المشاركة بالعتبة. هذا يجعل الاسترداد يتطلب عاملين:

شيء تملكه: على الأقل k حصص
شيء تعرفه: عبارة المرور

لماذا encrypt-then-split

تشفير السر مرة واحدة ثم تقسيمه يعطي ميزتين:

يمكنك التحقق من صحة الحصص (عبر وسم BLAKE3) بدون عبارة المرور.
لا يتم فك التشفير إلا بعد التأكد من تطابق مجموعة الحصص.

لماذا Argon2id لاشتقاق المفتاح

إذا حصل مهاجم على k حصص، يمكنه إعادة تركيب النص المشفّر ومحاولة تخمين عبارة المرور بشكل دون اتصال. وظيفة KDF هي جعل هذه المحاولة مكلفة.

Argon2id يُنصح به على نطاق واسع لأنه:

Memory-hard (أصعب على GPU/ASIC من PBKDF2).
يقلل بعض مخاوف side-channels مقارنة بـ Argon2d.
قابل للضبط (وقت/ذاكرة/توازي) بحيث يمكن رفع الكلفة مستقبلاً.

Safeparts يخزن إعدادات Argon2 داخل الحصص كي لا تنكسر حصص قديمة إذا تغيرت الافتراضات الافتراضية.

الإعدادات الافتراضية الحالية (قد تتغير) تقريباً:

الذاكرة: 64 MiB
time cost: 3
parallelism: 1

لماذا ChaCha20-Poly1305 للتشفير

ChaCha20-Poly1305 هو AEAD (تشفير مُصادق عليه). يوفر:

سرية: لا يمكن معرفة السر دون المفتاح.
سلامة/أصالة للنص المشفّر: عبارة مرور خاطئة أو عبث بالبيانات يؤدي إلى فشل فك التشفير.

يُستخدم كثيراً في الأدوات متعددة المنصات لأنه سريع وثابت زمنياً حتى على أنظمة لا تملك تسريع AES.

AES-GCM بديل قوي ومعياري أيضاً؛ اختيار ChaCha20-Poly1305 هنا أساسه الاتساق في الأداء والسلوك عبر الأجهزة.

الترميزات (سلامة بشرية وآلية)

الترميز يتعلق بـ الموثوقية التشغيلية: هل يمكنك حفظ الحصة ثم إعادة إدخالها لاحقاً دون أخطاء؟

base64url: صغير ومناسب للأتمتة.
base58check: يتجنب أحرفاً ملتبسة ويضيف checksum.
mnemo-words: كلمات + CRC16 لكشف كثير من أخطاء الكتابة.
mnemo-bip39: عبارات صالحة وفق BIP-39 مع framing للحزم متعددة الأجزاء.

راجع الترميزات لاختيار الصيغة.

إجراءات أمان موصى بها

إجراء التقسيم (إنشاء الحصص)

اختر k وn بناءً على أشخاص ومواقع يمكنك تنسيقها واقعياً وقت الضغط.
استخدم بيئة نظيفة:
- يفضّل دون اتصال.
- عطّل سجل الحافظة (clipboard history) وتسجيل الشاشة إن أمكن.
- تجنب الأدوات التي تسجل المدخلات.
إن استخدمت عبارة مرور:
- استخدم عبارة مرور عالية العشوائية.
- تجنب تمريرها في سطر الأوامر؛ يفضّل ملفاً حيث يتوفر ذلك.
أنشئ الحصص.
وزع الحصص عبر أسباب فشل مستقلة (أشخاص/أجهزة/مواقع).
احتفظ بدليل إجراءات يوضح من يحمل أي حصة وكيف تتواصل معه.
نفّذ تجربة استرداد (يفضل أولاً بسر اصطناعي ثم بالخطة الفعلية).

إجراء الاسترداد (جمع الحصص)

اجمع على الأقل k حصص.
فك ترميزها في بيئة مضبوطة.
نفذ الاسترداد والتحقق من السلامة (Safeparts يقوم بذلك تلقائياً).
إن كانت مشفرة، فك التشفير باستخدام عبارة المرور.
تعامل مع الناتج كبيانات حساسة:
- تجنب حفظه على القرص إلا للضرورة.
- دوّر/بدّل السر إذا تم الاسترداد في بيئة غير موثوقة.

عند الشك في تسرب أو اختراق

إذا شككت أن حصة نُسخت أو صُورت أو سُرقت، اعتبرها مخترقة.
إذا كان من المحتمل أن يصل عدد الحصص المخترقة إلى k، اعتبر السر مخترقاً.
الأفضل عملياً: استرداد السر، تدويره (إن أمكن)، ثم إعادة تقسيمه لمجموعة جديدة.

الحدود / ما لا يقدمه Safeparts

لا يوجد VSS (verifiable secret sharing): حامل حصة خبيث يمكنه إعطاء حصة خاطئة والتسبب في فشل الاسترداد.
لا يوجد تحديث للحصص بدون استرداد السر.
لا حماية إذا امتلك ائتلاف شرعي k حصص.
أمان عبارة المرور يعتمد على قوتها؛ Argon2id يرفع الكلفة لكنه لا يحمي عبارة مرور ضعيفة.

لجانب التخطيط البشري، راجع حالات الاستخدام والأمان.