এনক্রিপশন বাস্তবায়ন রেফারেন্স
যে এনক্রিপশন আসলে চলে তা যে এনক্রিপশন লেখা হয়েছে তার চেয়ে সংকীর্ণ, আর এই পৃষ্ঠাটি সেই ব্যবধান নিয়েই। libsodium sealed box-ই একমাত্র বার্তা এনক্রিপশন যা Railgun চালায় — এবং সেগুলি কেবল সেই ক্লায়েন্ট পথেই চলে যেখানে নেটিভ libsignal মডিউল অনুপস্থিত। Electron ডেস্কটপ বিল্ডে, যেখানে libsignal সত্যিই লোড হয়, সরাসরি বার্তা এনক্রিপ্ট করার হ্যান্ডলারটি এখনও একটি প্লেসহোল্ডার যা প্লেইনটেক্সটকে base64-এ এনকোড করে। কমিউনিটি ও চ্যানেল বার্তা কোনো পথেই এনক্রিপ্ট করা হয় না। এই পৃষ্ঠার দ্বিতীয়ার্ধে বর্ণিত Signal-ধাঁচের প্রোটোকলটি লেখা ও পর্যালোচিত হয়েছে, এবং আপনি ডাউনলোড করতে পারেন এমন কোনো ক্লায়েন্টের সঙ্গে যুক্ত নয়।
এটি একটি আর্কিটেকচার রেফারেন্স, স্বাধীন নিরাপত্তা অডিট নয়। বিভাগ 1 ও 2 বর্ণনা করে কী শিপ হয়। বিভাগ 4 থেকে 7 এমন একটি নকশা বর্ণনা করে যার দিকে Railgun কাজ করে চলেছে এবং সেগুলি সর্বত্র পরিকল্পিত হিসেবে চিহ্নিত। এখানকার কোনো কিছুকেই এই দাবি হিসেবে পড়া উচিত নয় যে কোনো Railgun ক্লায়েন্ট বর্তমানে পরিকল্পিত হিসেবে চিহ্নিত কোনো বৈশিষ্ট্য কার্যকর করে।
আজ কী শিপ হয়
| পথ | প্রক্রিয়া | অবস্থা |
|---|---|---|
| সরাসরি বার্তা — ব্রাউজার ও ডেভেলপমেন্ট বিল্ড | libsodium sealed box — X25519 কী চুক্তি, XSalsa20-Poly1305 প্রমাণীকৃত এনক্রিপশন। নেটিভ libsignal মডিউল অনুপস্থিত থাকলে এটি নির্বাচিত হয়। | এনক্রিপ্টেড |
| সরাসরি বার্তা — Electron ডেস্কটপ বিল্ড | libsignal লোড হয়, তাই encryptDm-কে Electron IPC হ্যান্ডলারে পাঠানো হয় — একটি প্লেসহোল্ডার যা প্লেইনটেক্সটকে base64-এ এনকোড করে। রিলে পাঠযোগ্য টেক্সট পায়। | এনক্রিপ্ট করা হয় না |
| কমিউনিটি ও চ্যানেল বার্তা | base64-এ মোড়া প্লেইনটেক্সট হিসেবে পাঠানো হয়। চ্যানেল এনক্রিপশন লেখা আছে কিন্তু তা একটি প্লেইনটেক্সট মার্কার ফেরত দেয়। | এনক্রিপ্ট করা হয় না |
| X3DH + Double Ratchet | libsignal-এর বিপরীতে বাস্তবায়িত, কেবল একটি টাইপ হিসেবে ইমপোর্ট করা। কোনো রানটাইম পথ একে ইনস্ট্যানশিয়েট করে না। | পরিকল্পিত |
| ব্যক্তিগত কী সংরক্ষণ | কী ডিভাইসেই তৈরি হয় এবং সেখানেই রাখা হয়। কোনো কোড পথ ব্যক্তিগত বা পরিচয় কী উপাদান প্রেরণ করে না। | বাস্তবায়িত |
1. Sealed box — যে এনক্রিপশন চলে
Railgun যেখানে আদৌ কোনো সরাসরি বার্তা এনক্রিপ্ট করে, সেখানে তা করে একটি libsodium sealed box দিয়ে — crypto_box_seal গঠন। এটি X25519 কী চুক্তির সঙ্গে XSalsa20-Poly1305 প্রমাণীকৃত এনক্রিপশন যুক্ত করে। এটি প্রকৃত, সুপর্যালোচিত ক্রিপ্টোগ্রাফি। এটি ইচ্ছাকৃতভাবে সরল একটি গঠনও বটে, এবং এর সীমাবদ্ধতাগুলি গুরুত্বপূর্ণ। কোন ক্লায়েন্টগুলি এতে পৌঁছায় তা বিভাগ 2-এর বিষয়: ব্রাউজার ও ডেভেলপমেন্ট বিল্ড পৌঁছায়; Electron ডেস্কটপ বিল্ড পৌঁছায় না।
একটি sealed box কীভাবে তৈরি হয়
// Sender has only the recipient's public key, PK_r
(pk_e, sk_e) = crypto_box_keypair() // fresh, single-use
nonce = BLAKE2b(pk_e || PK_r) // derived, not random
ct = crypto_box(plaintext, nonce, PK_r, sk_e)
sealed = pk_e || ct // ephemeral key is prepended
erase(sk_e)
প্রাপক বার্তার শুরু থেকে ক্ষণস্থায়ী পাবলিক কী উদ্ধার করে, নিজের ব্যক্তিগত কী দিয়ে একই শেয়ার্ড সিক্রেট পুনরায় গণনা করে, এবং বাক্সটি খোলে। Poly1305 ট্যাগের অর্থ হলো, পরিবর্তিত সাইফারটেক্সট আবর্জনায় ডিক্রিপ্ট হওয়ার বদলে খুলতেই ব্যর্থ হয়।
এটি আপনাকে যা দেয়
- • রিলের বিরুদ্ধে এবং তারের উপর থাকা যে কারও বিরুদ্ধে গোপনীয়তা।
- • অখণ্ডতা — কারচুপি ধরা পড়ে, নীরবে ডিক্রিপ্ট হয়ে যায় না।
- • প্রেরকের নাম-পরিচয়হীনতা: কে পাঠিয়েছে সে সম্পর্কে ক্ষণস্থায়ী কী কিছুই প্রকাশ করে না।
- • কোনো সেশন সেটআপ নেই, তাই প্রাপক অফলাইন থাকলেও এটি কাজ করে।
এটি আপনাকে যা দেয় না
- • কোনো ফরওয়ার্ড সিক্রেসি নেই। প্রাপকের দীর্ঘমেয়াদি ব্যক্তিগত কী তাঁকে পাঠানো প্রতিটি বার্তাই খুলে ফেলে। সেটি ফাঁস হলে ধরে রাখা সাইফারটেক্সটও তার সঙ্গে ফাঁস হয়ে যায়।
- • কোনো প্রেরক প্রমাণীকরণ নেই। একটি sealed box গঠনগতভাবেই নাম-পরিচয়হীন; কে লিখেছে সে সম্পর্কে এটি কিছুই প্রমাণ করে না।
- • আপস-পরবর্তী কোনো পুনরুদ্ধার নেই। কী আপস হওয়ার পর এগিয়ে যাওয়ার মতো কোনো ratchet নেই।
ঠিক এই তিনটি ফাঁক বন্ধ করার জন্যই X3DH ও Double Ratchet-এর অস্তিত্ব, আর সেজন্যই সেই কাজ চলছে। সেটি না আসা পর্যন্ত একটি sealed-box DM-এর সৎ সারসংক্ষেপ হলো: নিষ্ক্রিয় নেটওয়ার্ক পর্যবেক্ষক ও রিলের বিরুদ্ধে শক্তিশালী, কিন্তু যে প্রতিপক্ষ শেষ পর্যন্ত প্রাপকের ডিভাইস কী হাতে পায় তার বিরুদ্ধে দুর্বল। এই সারসংক্ষেপ কেবল সেখানেই প্রযোজ্য যেখানে এই কোড সত্যিই চলে।
2. কী এনক্রিপ্ট করা হয় না
কমিউনিটি ও চ্যানেল বার্তা — অধিকাংশ Railgun ব্যবহারকারী আসলে যা লেখেন তার সিংহভাগ — আজ কোনো ক্লায়েন্ট পথেই এনক্রিপ্ট করা হয় না। চ্যানেল এনক্রিপশন ফাংশনটি বিদ্যমান, এবং তা নিজের সম্পর্কে স্পষ্টবাদী: এটি একটি সতর্কবার্তা লগ করে এবং একটি মার্কার স্ট্রিং-এর পিছনে base64-এ মোড়া প্লেইনটেক্সট ফেরত দেয়, যাতে পরবর্তী পর্যায়ে কেউ একে সাইফারটেক্সট বলে ভুল না করে।
// What encryptChannel actually returns
logger.warn("Channel encryption not yet implemented")
ciphertext = base64("[DEVCRYPTO:PLAINTEXT]" + plaintext)
বাস্তব পরিণতি: কমিউনিটি ও চ্যানেলের বিষয়বস্তুর ক্ষেত্রে Railgun সার্ভার যেকোনো সাধারণ চ্যাট সার্ভারের মতোই অবস্থানে আছে। আপনি সেখানে যা লেখেন তা এটি পড়তে পারে। গ্রুপ কী বিতরণ — প্রতি-চ্যানেল একটি কী যা sealed box-এর ভিতরে সদস্যদের দেওয়া হয় — পরিকল্পিত সমাধান এবং তা শিপ করা হয়নি।
Electron ডেস্কটপ বিল্ডে সরাসরি বার্তা
দ্বিতীয় ফাঁকটি হলো অধিকাংশ মানুষ যে ক্লায়েন্ট চালান তাতে সরাসরি বার্তা, এবং এটি উল্টো করে বলে ফেলা সহজ, তাই কোড যেভাবে চালায় ঠিক সেই নির্বাচন-যুক্তি এখানে দেওয়া হলো। initCrypto() মূল প্রক্রিয়াকে জিজ্ঞাসা করে libsignal লোড হয়েছে কি না। @signalapp/libsignal-client একটি প্রকৃত নির্ভরতা এবং স্টার্টআপে আবশ্যক, তাই শিপ করা একটি Electron বিল্ডে এটি সত্যিই লোড হয় — আর সেই উত্তরই sealed-box বাস্তবায়নের বদলে Electron IPC বাস্তবায়নটি নির্বাচন করে। এর encryptDm crypto:encryptDm হ্যান্ডলারে পাঠিয়ে দেয়, যা একটি প্লেসহোল্ডার:
// crypto:encryptDm, Electron main process
const plaintextBytes = new TextEncoder().encode(plaintext)
ciphertext: toBase64(plaintextBytes) // not encryption
সুতরাং বিভাগ 1-এর sealed box-গুলিতে তখনই পৌঁছানো হয় যখন libsignal অনুপস্থিত — ব্রাউজারে এবং ডেভেলপমেন্টে। ডেস্কটপ ক্লায়েন্টে একটি সরাসরি বার্তা base64-এনকোডেড প্লেইনটেক্সট হিসেবেই রিলেতে পৌঁছায়। সেখানে libsignal লোড করা হয় একটি পরিচয় কী ও একটি প্রি-কী বান্ডল তৈরি করার জন্য; এটি কোনো সেশন প্রতিষ্ঠা করে না এবং কিছুই ratchet করে না — crypto:ensureDmSession একটি ডিবাগ লগ, যার কোনো বডি নেই।
3. Curve25519 — অন্তর্নিহিত বক্ররেখা
যে sealed box-গুলি শিপ হয় এবং যে X3DH নকশা শিপ হয় না, দুটিই একই উপবৃত্তীয় বক্ররেখার উপর দাঁড়িয়ে: Curve25519, যা উচ্চ-গতির Diffie-Hellman কী বিনিময়ের জন্য Daniel J. Bernstein নকশা করেছেন। এই বিভাগ বক্ররেখাটিরই বর্ণনা দেয়, এবং দুটির ক্ষেত্রেই প্রযোজ্য।
বক্ররেখার সমীকরণ
y² = x³ + 486662x² + x
over the prime field 𝔽ₚ where p = 2²⁵⁵ − 19
2²⁵⁵ − 19 মৌলিক সংখ্যাটি বেছে নেওয়া হয়েছে কারণ এটি অত্যন্ত দ্রুত মডিউলার গণিত সম্ভব করে। 486662 সহগটি বেছে নেওয়া হয়েছে কারণ এটিই সবচেয়ে ছোট মান যা প্রয়োজনীয় নিরাপত্তা বৈশিষ্ট্যসহ একটি নিরাপদ বক্ররেখা তৈরি করে।
কী তৈরি
1. ব্যক্তিগত কী: একটি CSPRNG (ক্রিপ্টোগ্রাফিকভাবে নিরাপদ ছদ্ম-এলোমেলো সংখ্যা জেনারেটর) ব্যবহার করে 32টি এলোমেলো বাইট তৈরি করুন। সর্বনিম্ন 3টি বিট ও সর্বোচ্চ বিটটি মুছে এবং দ্বিতীয়-সর্বোচ্চ বিটটি সেট করে কী-টি ক্ল্যাম্প করুন। এতে নিশ্চিত হয় যে কী-টি 8-এর গুণিতক এবং বৈধ পরিসরে আছে।
a = random(32 bytes)
a[0] &= 248 // Clear low 3 bits
a[31] &= 127 // Clear high bit
a[31] |= 64 // Set second-highest bit
2. পাবলিক কী: ভিত্তি বিন্দু G = 9-এর সঙ্গে ব্যক্তিগত কী-এর স্কেলার গুণন গণনা করুন।
A = a · G // Scalar multiplication on Curve25519
নিরাপত্তা নির্ভর করে উপবৃত্তীয় বক্ররেখা বিচ্ছিন্ন লগারিদম সমস্যা (ECDLP)-র উপর: A ও G দেওয়া থাকলে a উদ্ধার করা গণনাগতভাবে অসম্ভব। Curve25519 আনুমানিক 128 বিট নিরাপত্তা দেয়।
Diffie-Hellman কী বিনিময়
দুই পক্ষ (অ্যালিস ও বব) শেয়ার্ড সিক্রেট কখনও প্রেরণ না করেই তা গণনা করতে পারে:
Alice: a (private), A = a·G (public)
Bob: b (private), B = b·G (public)
Alice computes: S = a · B = a · (b·G)
Bob computes: S = b · A = b · (a·G)
Both arrive at S = ab·G — the same shared secret
যে আড়ি পাতে সে A ও B (দুটিই পাবলিক) জানলেও ECDLP সমাধান না করে S গণনা করতে পারে না। এটিই কম্পিউটেশনাল Diffie-Hellman (CDH) অনুমান।
একটি sealed box হলো এই বিনিময়ই, যার এক পক্ষকে ক্ষণস্থায়ী করে ফেলে দেওয়া হয়। নিচের X3DH হলো এই বিনিময়ই, ভিন্ন ভিন্ন কী জোড়ার উপর চারবার সম্পাদিত, যাতে ফলাফল বিষয়বস্তু গোপন রাখার পাশাপাশি উভয় পক্ষকে প্রমাণীকৃতও করে।
4. X3DH — বর্ধিত ত্রিগুণ Diffie-Hellman
পরিকল্পিতX3DH একটি কঠিন সমস্যার সমাধান করে: দুজন মানুষ কীভাবে একটি এনক্রিপ্টেড সেশন প্রতিষ্ঠা করবে যখন তাঁদের একজন অফলাইন? প্রথাগত Diffie-Hellman-এ উভয় পক্ষেরই অনলাইনে থাকা প্রয়োজন। অ্যাসিনক্রোনাস কী চুক্তি সম্ভব করতে X3DH আগে থেকে আপলোড করা কী বান্ডল ব্যবহার করে।
কী-এর প্রকারভেদ
পরিচয় কী (IK)
দীর্ঘমেয়াদি Curve25519 কী জোড়া। একবারই তৈরি হয়, ব্যবহারকারীকে ক্রিপ্টোগ্রাফিকভাবে শনাক্ত করে। ব্যবহারকারী পুনরায় নিবন্ধন না করলে কখনও বদলায় না।
স্বাক্ষরিত প্রি-কী (SPK)
মধ্যমেয়াদি Curve25519 কী জোড়া, পরিচয় কী দিয়ে স্বাক্ষরিত। পর্যায়ক্রমে ঘোরানো হয়। স্বাক্ষর প্রমাণ করে যে এটি পরিচয় কী-এর ধারকের।
একবার-ব্যবহার্য প্রি-কী (OPK)
ক্ষণস্থায়ী Curve25519 কী জোড়া, যা ব্যাচে আপলোড করা হয়। প্রতিটি একবার ব্যবহার করে মুছে ফেলা হয়। প্রাথমিক বার্তার জন্য এটি ফরওয়ার্ড সিক্রেসির একটি অতিরিক্ত স্তর দেয়।
ক্ষণস্থায়ী কী (EK)
প্রতিটি নতুন সেশনের জন্য প্রেরকের তৈরি করা একটি নতুন Curve25519 কী জোড়া। সার্ভারে কখনও সংরক্ষণ করা হয় না।
X3DH হ্যান্ডশেক
অ্যালিস যখন ববকে (যিনি অফলাইন থাকতে পারেন) বার্তা পাঠাতে চান, তখন তিনি সার্ভার থেকে ববের প্রি-কী বান্ডল আনেন এবং চারটি Diffie-Hellman গণনা সম্পাদন করেন:
// Alice has: IKₐ (her identity key), EKₐ (fresh ephemeral)
// Bob published: IKᵦ, SPKᵦ, OPKᵦ
DH1 = DH(IKₐ, SPKᵦ) // her identity ↔ his signed pre-key
DH2 = DH(EKₐ, IKᵦ) // her ephemeral ↔ his identity
DH3 = DH(EKₐ, SPKᵦ) // her ephemeral ↔ his signed pre-key
DH4 = DH(EKₐ, OPKᵦ) // her ephemeral ↔ his one-time pre-key
SK = KDF(DH1 || DH2 || DH3 || DH4)
// SK is the shared secret, derived via HKDF-SHA-256
চারটি DH অপারেশন কেন?
- DH1 পারস্পরিক প্রমাণীকরণ দেয় (উভয় পরিচয় কী জড়িত থাকে)
- DH2 নিশ্চিত করে যে ক্ষণস্থায়ী কী-টি ববের পরিচয়ের সঙ্গে বাঁধা
- DH3 ক্ষণস্থায়ী কী-এর মাধ্যমে ফরওয়ার্ড সিক্রেসি দেয়
- DH4 অতিরিক্ত ফরওয়ার্ড সিক্রেসি দেয়। কোনো OPK পাওয়া না গেলেও X3DH কেবল DH1–DH3 দিয়েই কাজ করে
DH1 হলো সেই অপারেশন যা একটি sealed box-এর নেই। এ কারণেই শিপ হওয়া পথটি আপনাকে বলতে পারে না বার্তাটি কার কাছ থেকে এসেছে।
KDF — কী উদ্ভবন ফাংশন
কাঁচা DH আউটপুটগুলি HKDF-SHA-256 (HMAC-ভিত্তিক কী উদ্ভবন ফাংশন) ব্যবহার করে একত্র করা হয়। HKDF সংযুক্ত DH আউটপুট থেকে এনট্রপি নিষ্কাশন করে এবং তাকে একটি সমরূপভাবে এলোমেলো শেয়ার্ড সিক্রেটে প্রসারিত করে:
PRK = HKDF-Extract(salt="", input=DH1||DH2||DH3||DH4)
SK = HKDF-Expand(PRK, info="RailGunX3DH", length=32)
5. Double Ratchet অ্যালগরিদম
পরিকল্পিতX3DH একবার প্রাথমিক শেয়ার্ড সিক্রেট প্রতিষ্ঠা করলে Double Ratchet দায়িত্ব নেয়। প্রতিটি বার্তার জন্য একটি নতুন অনন্য কী উদ্ভব করতে এটি দুটি পরস্পর-সংযুক্ত "ratchet" ব্যবহার করে। নকশাটি আগের বার্তাগুলিকে সুরক্ষিত রাখে এবং একটি নতুন ratchet ধাপের পর ভবিষ্যতের বার্তার সুরক্ষা পুনরুদ্ধার করার উদ্দেশ্যে তৈরি।
DH ratchet (অপ্রতিসম)
প্রতিবার কথোপকথনের দিক বদলালে (অ্যালিস → বব, তারপর বব → অ্যালিস), নতুন ক্ষণস্থায়ী কী ব্যবহার করে একটি নতুন Diffie-Hellman কী বিনিময় ঘটে। এটি রুট কী-কে সামনের দিকে "ratchet" করে:
dh_out = DH(my_ratchet_key, their_ratchet_key)
root_key, chain_key = KDF(root_key, dh_out)
এটিই আপস-পরবর্তী নিরাপত্তা দিত: যে আক্রমণকারী বর্তমান অবস্থা চুরি করে, একটি নতুন DH ratchet ধাপ ঘটামাত্র সে প্রবেশাধিকার হারায়।
প্রতিসম ratchet (হ্যাশ চেইন)
DH ratchet ধাপগুলির মাঝে, একটি হ্যাশ-ভিত্তিক ratchet প্রতিটি বার্তার জন্য চেইন কী থেকে একটি নতুন বার্তা কী উদ্ভব করে:
message_key = HMAC-SHA256(chain_key, 0x01)
chain_key = HMAC-SHA256(chain_key, 0x02)
প্রতিটি ধাপের পর পুরোনো চেইন কী মুছে ফেলা হয়। বার্তা কী ঠিক একটি বার্তাই এনক্রিপ্ট করে, তারপর মুছে ফেলা হয়। এটিই ফরওয়ার্ড সিক্রেসি ব্যবস্থা।
ratchet-এর অগ্রগতি
চিত্রায়িত করলে Double Ratchet দেখতে এমন। প্রতিটি তীর একটি একমুখী ফাংশন — আপনি সামনে যেতে পারেন কিন্তু কখনও পিছনে নয়:
Root Key Chain:
RK₀ ──DH──→ RK₁ ──DH──→ RK₂ ──DH──→ RK₃ ...
Each RK step produces a Chain Key:
↓ ↓ ↓
CK₀ CK₁ CK₂
↓ ↓ ↓
Each CK step produces Message Keys:
CK₀→MK₀ CK₁→MK₃ CK₂→MK₅
CK₀→MK₁ CK₁→MK₄ CK₂→MK₆
CK₀→MK₂ CK₂→MK₇
প্রতিটি MKₙ ঠিক একটি বার্তাই এনক্রিপ্ট করত এবং তারপর মুছে ফেলা হতো, তাই যে আক্রমণকারী MK₄ পায় সে MK₃ বা MK₅ উদ্ভব করতে পারত না। আজ যে sealed-box পথ শিপ হয়, সেখানে চুরি করার মতো কোনো প্রতি-বার্তা কী নেই এবং হেঁটে যাওয়ার মতো কোনো চেইনও নেই — সেখানে একটিই দীর্ঘমেয়াদি কী আছে যা সবকিছু খুলে দেয়।
6. ফরওয়ার্ড সিক্রেসি — এর জন্য কী লাগবে
পরিকল্পিতফরওয়ার্ড সিক্রেসির অর্থ হলো দীর্ঘমেয়াদি কী আপস হলেও অতীতের সেশন কী আপস হয় না। Railgun-এর কাছে আজ এটি নেই। দুটি ব্যবস্থা এটি দিতে পারত, এবং দুটিই উপরে বর্ণিত পরিকল্পিত প্রোটোকলের অংশ:
X3DH-এ ক্ষণস্থায়ী কী
প্রেরক প্রতিটি নতুন সেশনের জন্য একটি নতুন ক্ষণস্থায়ী কী জোড়া তৈরি করে এবং হ্যান্ডশেকের পর ব্যক্তিগত অর্ধেকটি মুছে ফেলে। যে আক্রমণকারী পরে উভয় পক্ষের পরিচয় কী চুরি করে, সেও সেশন সিক্রেট পুনর্গঠন করতে পারে না। sealed box প্রেরকের দিকে একটি নতুন ক্ষণস্থায়ী কী ব্যবহার করে ঠিকই — কিন্তু বিনিময়ে প্রাপকের অর্ধেকটি তাঁর দীর্ঘমেয়াদি কী, আর ঠিক সেই কারণেই বৈশিষ্ট্যটি টেকে না।
ratchet কী মুছে ফেলা
Double Ratchet ব্যবহারের পর পুরোনো চেইন কী ও বার্তা কী মুছে ফেলে। KDF চেইন একমুখী — CKₙ দেওয়া থাকলে আপনি CKₙ₊₁ গণনা করতে পারেন কিন্তু CKₙ₋₁ নয়, তাই T সময়ে ঘটা একটি আপস T-এর আগে পাঠানো কিছুই প্রকাশ করে না।
আপস-পরবর্তী নিরাপত্তা
DH ratchet ভবিষ্যৎ গোপনীয়তাও দেয়: যে আক্রমণকারী বর্তমান সেশন অবস্থা আপস করে, পরবর্তী ratchet ধাপে সে তা হারায়, কারণ ওই ধাপ এমন এলোমেলোতা আনে যা তার কাছে নেই। ratchet ছাড়া, আপস হওয়া একটি কী আক্রমণকারীর কাছে অনির্দিষ্টকাল ধরে কাজে লাগতে থাকে।
7. রিলে ও কিউ আর্কিটেকচার
Railgun এনভেলপ রিলে করে এবং অফলাইন ডেলিভারির জন্য সেগুলি সাময়িকভাবে কিউতে রাখতে পারে। রিলে এমনভাবে তৈরি যাতে তার বার্তার প্লেইনটেক্সট দরকার না হয়, কিন্তু আজ দুটি ক্ষেত্রে এটি প্লেইনটেক্সট পায়: চ্যানেল বার্তা, যা কোনো ক্লায়েন্টই এনক্রিপ্ট করে না, এবং Electron ডেস্কটপ বিল্ড থেকে আসা সরাসরি বার্তা, যার IPC হ্যান্ডলার এনক্রিপ্ট করার বদলে base64-এ এনকোড করে। sealed-box পথ থেকে আসা একটি সরাসরি বার্তা এমন সাইফারটেক্সট হিসেবে পৌঁছায় যা রিলে খুলতে পারে না।
সার্ভার যা দেখে
সার্ভার যা রাখে:
- • পাবলিক কী বান্ডল
- • ব্যবহারকারী নিবন্ধনের তথ্য
- • কমিউনিটি/চ্যানেল মেটাডেটা ও সদস্যপদ
- • sealed-box সাইফারটেক্সট যা এটি খুলতে পারে না (ব্রাউজার/ডেভ পথ থেকে আসা DM)
- • Electron ডেস্কটপ বিল্ড থেকে আসা base64-এনকোডেড DM প্লেইনটেক্সট
- • চ্যানেল বার্তার বিষয়বস্তু, যতক্ষণ না চ্যানেল এনক্রিপশন শিপ হয়
- • প্রমাণীকরণ অডিট রেকর্ড
সার্ভার যা কখনও পায় না:
- • ব্যক্তিগত বা পরিচয় কী
- • ক্লায়েন্ট সেশন অবস্থা
- • আপনার বার্তা ইতিহাসের কোনো স্থায়ী অনুলিপি
অনলাইন প্রাপকদের কাছে বার্তা WebSocket-এর মাধ্যমে রিয়েল টাইমে রিলে করা হয়। অফলাইন ডিভাইসের জন্য এনভেলপগুলি সর্বোচ্চ 30 দিনের TTL সহ Redis-এ কিউ করা হয় এবং ডিভাইস প্রাপ্তি স্বীকার করামাত্র মুছে ফেলা হয়। সার্ভারে কোনো বার্তা আর্কাইভ নেই — ক্লায়েন্ট ইতিহাস আপনার নিজের ডিভাইসের স্থানীয় স্টোরেজে থাকে, তাই ডিভাইস হারানো মানে ইতিহাস হারানো।
8. নিরাপত্তা বৈশিষ্ট্যের সারসংক্ষেপ
| বৈশিষ্ট্য | প্রক্রিয়া | অবস্থা |
|---|---|---|
| DM গোপনীয়তা | sealed box কেবল ব্রাউজার/ডেভেলপমেন্ট পথে; Electron ডেস্কটপ হ্যান্ডলার base64-এ এনকোড করে | আংশিক |
| DM অখণ্ডতা | sealed-box পথে Poly1305 ট্যাগ; Electron ডেস্কটপ পথ অপ্রমাণীকৃত base64 পাঠায় | আংশিক |
| কী ডিভাইসেই থাকে | স্থানীয় কী স্টোর; কোনো কোড পথ ব্যক্তিগত কী প্রেরণ করে না | বাস্তবায়িত |
| অফলাইন ডেলিভারি | এনভেলপ 30 দিনের TTL সহ Redis-এ কিউ করা হয়, প্রাপ্তিস্বীকারে মুছে ফেলা হয় | বাস্তবায়িত |
| চ্যানেল গোপনীয়তা | গ্রুপ কী বিতরণ বাস্তবায়িত নয়; বিষয়বস্তু পাঠযোগ্য অবস্থাতেই পাঠানো হয় | বাস্তবায়িত নয় |
| প্রেরক প্রমাণীকরণ | sealed box গঠনগতভাবেই নাম-পরিচয়হীন | বাস্তবায়িত নয় |
| ফরওয়ার্ড সিক্রেসি | এর জন্য Double Ratchet প্রয়োজন, যা কোনো ক্লায়েন্ট ইনস্ট্যানশিয়েট করে না | পরিকল্পিত |
| আপস-পরবর্তী পুনরুদ্ধার | এর জন্য DH ratchet প্রয়োজন, যা কোনো ক্লায়েন্ট ইনস্ট্যানশিয়েট করে না | পরিকল্পিত |
| স্বাধীন অডিট | সম্পন্ন হওয়া কোনো তৃতীয়-পক্ষ ক্রিপ্টোগ্রাফিক অডিটের দাবি করা হয় না | সম্পন্ন হয়নি |
| পোস্ট-কোয়ান্টাম নিশ্চয়তা | ঢালাওভাবে কোনো পোস্ট-কোয়ান্টাম নিরাপত্তার নিশ্চয়তা দাবি করা হয় না | দাবি করা হয়নি |
এই পৃষ্ঠা কোথা থেকে এসেছে
উপরের প্রতিটি অবস্থা কোনো নকশা নথি থেকে নয়, ক্লায়েন্ট সোর্স কোড থেকে পড়া হয়েছে। ক্লায়েন্ট রিপোজিটরি বর্তমানে সর্বজনীন নয়, তাই আমরা আপনাকে নিজে যাচাই করতে বলতে পারি না — আর সেটিই একটি কারণ যে এই পৃষ্ঠাকে প্রমাণ নয়, একটি প্রকাশ হিসেবে বিবেচনা করা উচিত। কোনো নির্দিষ্ট দাবি সম্পর্কে প্রশ্ন security@railgun.chat-এ স্বাগত।