Kriptografi

Şifreleme Uygulama Referansı

Çalışan şifreleme, yazılmış olan şifrelemeden daha dardır ve bu sayfa tam da bu boşluk için vardır. Railgun'ın yürüttüğü tek mesaj şifrelemesi libsodium sealed box'larıdır — ve bunlar yalnızca yerel libsignal modülünün bulunmadığı istemci yolunda çalışır. libsignal'in gerçekten yüklendiği Electron masaüstü sürümünde, doğrudan mesajları şifreleyen işleyici hâlâ düz metni base64 ile kodlayan bir yer tutucudur. Topluluk ve kanal mesajları hiçbir yolda şifrelenmez. Bu sayfanın ikinci yarısında anlatılan Signal tarzı protokol yazılmış ve gözden geçirilmiştir, ancak indirebileceğiniz hiçbir istemciye bağlanmamıştır.

Bu bir mimari referanstır, bağımsız bir güvenlik denetimi değildir. 1. ve 2. bölümler yayınlanan durumu anlatır. 4 ile 7 arasındaki bölümler Railgun'ın hedeflediği bir tasarımı anlatır ve baştan sona Planlanan olarak etiketlenmiştir. Buradaki hiçbir ifade, bir Railgun istemcisinin planlanan olarak işaretlenmiş bir özelliği şu anda uyguladığı iddiası olarak okunmamalıdır.

Bugün yayında olanlar

Yol	Mekanizma	Durum
Doğrudan mesajlar — tarayıcı ve geliştirme sürümleri	libsodium sealed box — X25519 anahtar anlaşması, XSalsa20-Poly1305 kimlik doğrulamalı şifreleme. Yerel libsignal modülü bulunmadığında seçilir.	Şifreli
Doğrudan mesajlar — Electron masaüstü sürümü	libsignal yüklenir, bu nedenle encryptDm Electron IPC işleyicisine yönlendirilir — düz metni base64 ile kodlayan bir yer tutucu. Aktarma sunucusu okunabilir metin alır.	Şifrelenmiyor
Topluluk ve kanal mesajları	base64 ile sarmalanmış düz metin olarak gönderilir. Kanal şifrelemesi yazılmıştır ancak düz metin işaretçisi döndürür.	Şifrelenmiyor
X3DH + Double Ratchet	libsignal'e karşı uygulanmıştır, yalnızca tür olarak içe aktarılır. Hiçbir çalışma zamanı yolu onu örneklemez.	Planlanan
Özel anahtar depolama	Anahtarlar cihazda üretilir ve cihazda tutulur. Hiçbir kod yolu özel anahtar veya kimlik anahtarı materyalini iletmez.	Uygulandı

1. Sealed box'lar — çalışan şifreleme

Railgun bir doğrudan mesajı şifrelediği yerlerde, bunu bir libsodium sealed box ile yapar — crypto_box_seal yapısı. Bu yapı, X25519 anahtar anlaşmasını XSalsa20-Poly1305 kimlik doğrulamalı şifrelemeyle birleştirir. Bu gerçek, iyi incelenmiş bir kriptografidir. Aynı zamanda kasıtlı olarak basit bir yapıdır ve sınırları önemlidir. Hangi istemcilerin buna ulaştığı 2. bölümün konusudur: tarayıcı ve geliştirme sürümleri ulaşır; Electron masaüstü sürümü ulaşmaz.

Bir sealed box nasıl oluşturulur

// 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)

Alıcı, geçici genel anahtarı mesajın başından geri elde eder, kendi özel anahtarıyla aynı paylaşılan sırrı yeniden hesaplar ve kutuyu açar. Poly1305 etiketi sayesinde değiştirilmiş bir şifreli metin, anlamsız veriye çözülmek yerine hiç açılamaz.

Bunun size sağladıkları

• Aktarma sunucusuna ve hat üzerindeki herkese karşı gizlilik.
• Bütünlük — kurcalama tespit edilir, sessizce çözülmez.
• Gönderen anonimliği: geçici anahtar, mesajı kimin gönderdiği hakkında hiçbir şey açığa çıkarmaz.
• Oturum kurulumu gerekmez, bu nedenle alıcı çevrimdışıyken de çalışır.

Bunun size sağlamadıkları

• İleri gizlilik yoktur. Alıcının uzun ömürlü özel anahtarı, kendisine gönderilmiş her mesajı açar. Bu anahtar sızarsa, yakalanmış şifreli metinler de onunla birlikte sızar.
• Gönderen kimlik doğrulaması yoktur. Bir sealed box yapısı gereği anonimdir; onu kimin yazdığı hakkında hiçbir şey kanıtlamaz.
• Ele geçirilme sonrası kurtarma yoktur. Bir anahtarın ele geçirilmesinin ötesine geçmeyi sağlayacak hiçbir ratchet mekanizması yoktur.

Bu üç boşluk, tam olarak X3DH ve Double Ratchet'in kapatmak için var olduğu boşluklardır; bu çalışmanın sürmesinin nedeni de budur. Bu iş tamamlanana kadar, sealed box ile gönderilen bir doğrudan mesajın dürüst özeti şudur: pasif bir ağ gözlemcisine ve aktarma sunucusuna karşı güçlü, sonunda alıcının cihaz anahtarını ele geçiren bir saldırgana karşı zayıf. Bu özet yalnızca bu kodun gerçekten çalıştığı yerler için geçerlidir.

2. Neler şifrelenmiyor

Topluluk ve kanal mesajları — çoğu Railgun kullanıcısının aslında yazdığı içeriğin büyük kısmı — bugün hiçbir istemci yolunda şifrelenmiyor. Kanal şifreleme işlevi mevcuttur ve kendisi hakkında açık sözlüdür: bir uyarıyı günlüğe yazar ve düz metni bir işaretçi dizesinin arkasında base64 ile sarmalanmış olarak döndürür; böylece aşağı akıştaki hiç kimse onu şifreli metin sanmaz.

// What encryptChannel actually returns

logger.warn("Channel encryption not yet implemented")

ciphertext = base64("[DEVCRYPTO:PLAINTEXT]" + plaintext)

Pratik sonuç: topluluk ve kanal içeriği açısından Railgun sunucusu, sıradan herhangi bir sohbet sunucusuyla aynı konumdadır. Orada yazdıklarınızı okuyabilir. Grup anahtarı dağıtımı — üyelere sealed box'lar içinde verilen, kanal başına bir anahtar — planlanan çözümdür ve yayınlanmamıştır.

Electron masaüstü sürümünde doğrudan mesajlar

İkinci boşluk, çoğu insanın kullandığı istemcideki doğrudan mesajlardır ve bunu ters ifade etmek kolaydır; bu yüzden seçim mantığı, kodun onu yürüttüğü haliyle şudur. initCrypto() ana sürece libsignal'in yüklenip yüklenmediğini sorar. @signalapp/libsignal-client gerçek bir bağımlılıktır ve başlangıçta gereklidir, dolayısıyla yayınlanmış bir Electron sürümünde yüklenir — ve sealed box uygulaması yerine Electron IPC uygulamasını seçen şey işte bu yanıttır. Onun encryptDm işlevi, bir yer tutucu olan crypto:encryptDm işleyicisine iletir:

// crypto:encryptDm, Electron main process

const plaintextBytes = new TextEncoder().encode(plaintext)

ciphertext: toBase64(plaintextBytes) // not encryption

Yani 1. bölümdeki sealed box'lara, libsignal bulunmadığında ulaşılır — tarayıcıda ve geliştirme ortamında. Masaüstü istemcisinde bir doğrudan mesaj, aktarma sunucusuna base64 ile kodlanmış düz metin olarak ulaşır. libsignal orada bir kimlik anahtarı ve bir ön anahtar paketi üretmek için yüklenir; hiçbir oturum kurmaz ve hiçbir şeyi ratchet'lemez — crypto:ensureDmSession gövdesi olmayan bir hata ayıklama günlüğüdür.

3. Curve25519 — temel eğri

Hem yayınlanan sealed box'lar hem de yayınlanmayan X3DH tasarımı aynı eliptik eğriye dayanır: yüksek hızlı Diffie-Hellman anahtar değişimi için Daniel J. Bernstein tarafından tasarlanan Curve25519. Bu bölüm eğrinin kendisini anlatır ve her ikisi için de geçerlidir.

Eğri Denklemi

y² = x³ + 486662x² + x

over the prime field 𝔽ₚ where p = 2²⁵⁵ − 19

2²⁵⁵ − 19 asal sayısı, son derece hızlı modüler aritmetiğe olanak tanıdığı için seçilmiştir. 486662 katsayısı, gerekli güvenlik özelliklerine sahip güvenli bir eğri üreten en küçük değer olduğu için seçilmiştir.

Anahtar Üretimi

1. Özel anahtar: Bir CSPRNG (kriptografik olarak güvenli sözde rastgele sayı üreteci) kullanarak 32 rastgele bayt üretin. En düşük 3 biti ve en yüksek biti sıfırlayıp ikinci en yüksek biti ayarlayarak anahtarı kelepçeleyin. Bu, anahtarın 8'in katı olmasını ve geçerli aralıkta bulunmasını sağlar.

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. Genel anahtar: Özel anahtarın G = 9 temel noktasıyla skaler çarpımını hesaplayın.

A = a · G // Scalar multiplication on Curve25519

Güvenlik, Eliptik Eğri Ayrık Logaritma Problemi (ECDLP) üzerine kuruludur: A ve G verildiğinde a değerini geri elde etmek hesaplama açısından mümkün değildir. Curve25519 yaklaşık 128 bitlik güvenlik sağlar.

Diffie-Hellman Anahtar Değişimi

İki taraf (Alice ve Bob), paylaşılan bir sırrı hiç iletmeden hesaplayabilir:

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 ve B değerlerini (her ikisi de genel) bilen bir dinleyici, ECDLP çözülmeden S değerini hesaplayamaz. Bu, Hesaplamalı Diffie-Hellman (CDH) varsayımıdır.

Bir sealed box, bu değişimin bir tarafı geçici hale getirilip atılmış halidir. Aşağıdaki X3DH ise bu değişimin farklı anahtar çiftleri üzerinde dört kez gerçekleştirilmiş halidir; böylece sonuç, içeriği gizlemenin yanı sıra her iki tarafın kimliğini de doğrular.

4. X3DH — Genişletilmiş Üçlü Diffie-Hellman

PLANLANAN

libsignal'e karşı yazılmıştır ve kod tabanında incelenebilir. Yalnızca tür olarak içe aktarılır — yayınlanan hiçbir istemci onu oluşturmaz. Bu bölümdeki her şeyi mevcut davranış değil, hedeflenen tasarım olarak değerlendirin.

X3DH zor bir sorunu çözer: taraflardan biri çevrimdışıyken iki kişi nasıl şifreli bir oturum kurar? Geleneksel Diffie-Hellman her iki tarafın da çevrimiçi olmasını gerektirir. X3DH, eşzamansız anahtar anlaşmasını mümkün kılmak için önceden yüklenmiş anahtar paketleri kullanır.

Anahtar Türleri

Kimlik Anahtarı (IK)

Uzun ömürlü Curve25519 anahtar çifti. Bir kez üretilir, kullanıcıyı kriptografik olarak tanımlar. Kullanıcı yeniden kaydolmadıkça hiç değişmez.

İmzalı Ön Anahtar (SPK)

Kimlik Anahtarı tarafından imzalanmış, orta ömürlü Curve25519 anahtar çifti. Periyodik olarak döndürülür. İmza, anahtarın kimlik anahtarı sahibine ait olduğunu kanıtlar.

Tek Kullanımlık Ön Anahtar (OPK)

Toplu olarak yüklenen geçici Curve25519 anahtar çiftleri. Her biri bir kez kullanılır, sonra silinir. İlk mesaj için ek bir ileri gizlilik katmanı sağlar.

Geçici Anahtar (EK)

Gönderenin her yeni oturum için ürettiği taze bir Curve25519 anahtar çifti. Sunucu tarafında hiçbir zaman saklanmaz.

X3DH El Sıkışması

Alice, Bob'a (çevrimdışı olabilir) mesaj göndermek istediğinde, Bob'un ön anahtar paketini sunucudan alır ve dört Diffie-Hellman hesaplaması gerçekleştirir:

// 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

Neden dört DH işlemi?

DH1 karşılıklı kimlik doğrulaması sağlar (her iki kimlik anahtarı da işin içindedir)
DH2 geçici anahtarın Bob'un kimliğine bağlı olmasını sağlar
DH3 geçici anahtar aracılığıyla ileri gizlilik sağlar
DH4 ek ileri gizlilik sağlar. Kullanılabilir bir OPK yoksa, X3DH yalnızca DH1–DH3 ile de çalışır

DH1, bir sealed box'ta bulunmayan işlemdir. Yayınlanan yolun size bir mesajın kimden geldiğini söyleyememesinin nedeni budur.

KDF — Anahtar Türetme Fonksiyonu

Ham DH çıktıları HKDF-SHA-256 (HMAC tabanlı Anahtar Türetme Fonksiyonu) kullanılarak birleştirilir. HKDF, birleştirilmiş DH çıktılarından entropi çıkarır ve bunu düzgün dağılımlı rastgele bir paylaşılan sırra genişletir:

PRK = HKDF-Extract(salt="", input=DH1||DH2||DH3||DH4)

SK = HKDF-Expand(PRK, info="RailGunX3DH", length=32)

5. Double Ratchet Algoritması

PLANLANAN

Bugün hiçbir Railgun sürümü anahtarları ratchet'lemez. Sealed box yolunda her doğrudan mesaj aynı uzun ömürlü alıcı anahtarına şifrelenir; Electron masaüstü yolunda ise hiç şifrelenmez.

X3DH ilk paylaşılan sırrı kurduktan sonra devreyi Double Ratchet alır. Her mesaj için yeni ve benzersiz bir anahtar türetmek üzere iç içe geçmiş iki "ratchet" kullanır. Tasarım, önceki mesajları korur ve yeni bir ratchet adımından sonra gelecekteki mesajların korumasını geri kazandırmayı amaçlar.

DH Ratchet (Asimetrik)

Konuşmanın yönü her değiştiğinde (Alice → Bob, sonra Bob → Alice), taze geçici anahtarlar kullanılarak yeni bir Diffie-Hellman anahtar değişimi gerçekleşir. Bu işlem kök anahtarı ileriye doğru "ratchet"ler:

dh_out = DH(my_ratchet_key, their_ratchet_key)

root_key, chain_key = KDF(root_key, dh_out)

Ele geçirilme sonrası güvenliği sağlayacak olan şey budur: mevcut durumu çalan bir saldırgan, yeni bir DH ratchet adımı gerçekleştiğinde erişimini kaybeder.

Simetrik Ratchet (Karma Zinciri)

DH ratchet adımları arasında, karma tabanlı bir ratchet her mesaj için zincir anahtarından yeni bir mesaj anahtarı türetir:

message_key = HMAC-SHA256(chain_key, 0x01)

chain_key = HMAC-SHA256(chain_key, 0x02)

Eski zincir anahtarı her adımdan sonra silinir. Mesaj anahtarı tam olarak bir mesajı şifreler, ardından silinir. İleri gizlilik mekanizması budur.

Ratchet İlerleyişi

Görselleştirildiğinde Double Ratchet şöyle görünür. Her ok tek yönlü bir fonksiyondur — ileri gidebilirsiniz ama asla geri gidemezsiniz:

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₇

Her MKₙ tam olarak bir mesajı şifreleyecek ve ardından silinecektir; böylece MK₄ anahtarını ele geçiren bir saldırgan MK₃ veya MK₅ anahtarını türetemez. Bugün yayınlanan sealed box yolunda ise çalınacak mesaj başına bir anahtar da, yürünecek bir zincir de yoktur — her şeyi açan tek bir uzun ömürlü anahtar vardır.

6. İleri gizlilik — neler gerekir

PLANLANAN

İleri gizlilik, uzun ömürlü anahtarların ele geçirilmesinin geçmiş oturum anahtarlarını ele geçirmemesi anlamına gelir. Railgun bugün buna sahip değildir. İki mekanizma bunu sağlayabilirdi ve her ikisi de yukarıdaki planlanan protokole aittir:

X3DH'deki geçici anahtarlar

Gönderen, her yeni oturum için taze bir geçici anahtar çifti üretir ve el sıkışmasından sonra bunun özel yarısını siler. Daha sonra her iki tarafın kimlik anahtarlarını çalan bir saldırgan bile oturum sırrını yeniden oluşturamaz. Sealed box'lar gönderen tarafında gerçekten taze bir geçici anahtar kullanır — ancak değişimin alıcı tarafındaki yarısı alıcının uzun ömürlü anahtarıdır ve bu özelliğin sağlanmamasının nedeni tam olarak budur.

Ratchet anahtarlarının silinmesi

Double Ratchet, eski zincir anahtarlarını ve mesaj anahtarlarını kullanımdan sonra siler. KDF zinciri tek yönlüdür — CKₙ verildiğinde CKₙ₊₁ hesaplanabilir ama CKₙ₋₁ hesaplanamaz; bu nedenle T anındaki bir ele geçirilme, T'den önce gönderilenler hakkında hiçbir şey açığa çıkarmaz.

Ele geçirilme sonrası güvenlik

DH ratchet ayrıca gelecek gizliliği sağlar: mevcut oturum durumunu ele geçiren bir saldırgan, sahip olmadığı rastgeleliği devreye sokan bir sonraki ratchet adımında bunu kaybeder. Ratchet olmadan, ele geçirilmiş bir anahtar saldırgan için süresiz olarak kullanışlı kalır.

7. Aktarma ve Kuyruk Mimarisi

Railgun zarfları aktarır ve çevrimdışı teslimat için geçici olarak kuyruğa alabilir. Aktarma sunucusu mesaj düz metnine ihtiyaç duymayacak şekilde inşa edilmiştir, ancak bugün iki durumda düz metin alır: hiçbir istemcinin şifrelemediği kanal mesajları ve IPC işleyicisi şifrelemek yerine base64 ile kodlayan Electron masaüstü sürümünden gelen doğrudan mesajlar. Sealed box yolundan gelen bir doğrudan mesaj ise, aktarma sunucusunun açamayacağı şifreli metin olarak ulaşır.

Sunucunun Gördükleri

Sunucu şunları tutar:

• Genel anahtar paketleri
• Kullanıcı kayıt bilgileri
• Topluluk/kanal meta verileri ve üyelik bilgileri
• Açamadığı sealed box şifreli metni (tarayıcı/geliştirme yolundan gelen DM'ler)
• Electron masaüstü sürümünden gelen base64 ile kodlanmış DM düz metni
• Kanal şifrelemesi yayınlanana kadar kanal mesajı içeriği
• Kimlik doğrulama denetim kayıtları

Sunucu şunları asla almaz:

• Özel anahtarlar veya kimlik anahtarları
• İstemci oturum durumu
• Mesaj geçmişinizin kalıcı bir kopyası

Mesajlar çevrimiçi alıcılara WebSocket üzerinden gerçek zamanlı olarak aktarılır. Çevrimdışı cihazlar için zarflar en fazla 30 günlük TTL ile Redis'te kuyruğa alınır ve cihaz onları onayladığında silinir. Sunucu tarafında mesaj arşivi yoktur — istemci geçmişi kendi cihazınızdaki yerel depolamada bulunur, dolayısıyla kaybedilen bir cihaz kaybedilen bir geçmiş demektir.

8. Güvenlik Özellikleri Özeti

Özellik	Mekanizma	Durum
DM gizliliği	Yalnızca tarayıcı/geliştirme yolunda sealed box'lar; Electron masaüstü işleyicisi base64 ile kodlar	Kısmi
DM bütünlüğü	Sealed box yolunda Poly1305 etiketi; Electron masaüstü yolu kimliği doğrulanmamış base64 gönderir	Kısmi
Anahtarlar cihazda kalır	Yerel anahtar deposu; hiçbir kod yolu özel anahtarları iletmez	Uygulandı
Çevrimdışı teslimat	Zarflar 30 günlük TTL ile Redis'te kuyruğa alınır, onaylandığında silinir	Uygulandı
Kanal gizliliği	Grup anahtarı dağıtımı uygulanmamıştır; içerik okunabilir şekilde gönderilir	Uygulanmadı
Gönderen kimlik doğrulaması	Sealed box'lar yapıları gereği anonimdir	Uygulanmadı
İleri gizlilik	Hiçbir istemcinin örneklemediği Double Ratchet'i gerektirir	Planlanan
Ele geçirilme sonrası kurtarma	Hiçbir istemcinin örneklemediği DH ratchet'ini gerektirir	Planlanan
Bağımsız denetim	Tamamlanmış hiçbir üçüncü taraf kriptografi denetimi iddia edilmemektedir	Tamamlanmadı
Kuantum sonrası garanti	Genel geçer hiçbir kuantum sonrası güvenlik garantisi iddia edilmemektedir	İddia edilmiyor

Bu sayfa neye dayanıyor

Yukarıdaki her durum, bir tasarım belgesinden değil, istemci kaynak kodundan okunarak yazılmıştır. İstemci deposu şu anda herkese açık değildir, bu nedenle sizden kendiniz kontrol etmenizi isteyemeyiz — bu da bu sayfayı bir kanıt olarak değil, bir açıklama olarak değerlendirmeniz için bir nedendir. Belirli bir iddiaya ilişkin sorularınızı security@railgun.chat adresine bekleriz.

Sunucunun okuyabildikleri Threat Shield durumu →