Post-Kuantum Kripto Protokolleri

Durum

Genel Bakış

Uygun kuantum sonrası (PQ) kriptografi için araştırma ve rekabet on yıldır devam ederken, seçenekler yakın zamana kadar netlik kazanmamıştı.

2022’de PQ kripto’nun etkilerini incelemeye başladık zzz.i2p .

TLS standartları son iki yılda hibrit şifreleme desteği ekledi ve Chrome ve Firefox’taki destek sayesinde artık internetdeki şifrelenmiş trafiğin önemli bir bölümünde kullanılmakta Cloudflare .

NIST yakın zamanda kuantum sonrası kriptografi için önerilen algoritmaları tamamlayıp yayınladı NIST . Birçok yaygın kriptografi kütüphanesi artık NIST standartlarını destekliyor veya yakın gelecekte destek yayınlayacak.

Hem Cloudflare hem de NIST geçişin hemen başlaması gerektiğini öneriyor. Ayrıca 2022 NSA PQ SSS’ye bakın NSA . I2P güvenlik ve kriptografide öncü olmalıdır. Önerilen algoritmaları uygulamanın zamanı geldi. Esnek kripto tipi ve imza tipi sistemimizi kullanarak, hibrit kripto ve PQ ile hibrit imzalar için tipler ekleyeceğiz.

Hedefler

• PQ-dirençli algoritmaları seç
• Uygun yerlerde I2P protokollerine yalnızca-PQ ve hibrit algoritmaları ekle
• Birden fazla varyant tanımla
• Uygulama, test, analiz ve araştırma sonrasında en iyi varyantları seç
• Desteği aşamalı olarak ve geriye dönük uyumluluk ile ekle

Hedef Olmayanlar

• Tek yönlü (Noise N) şifreleme protokollerini değiştirmeyin
• SHA256’dan uzaklaşmayın, yakın vadede PQ tarafından tehdit altında değil
• Şu anda nihai tercih edilen varyantları seçmeyin

Tehdit Modeli

• OBEP veya IBGW’deki router’lar, muhtemelen işbirliği yaparak, garlic mesajlarını daha sonra şifrelemesini çözmek için saklama (forward secrecy)
• Ağ gözlemcilerinin transport mesajlarını daha sonra şifrelemesini çözmek için saklama (forward secrecy)
• Ağ katılımcılarının RI, LS, streaming, datagram’lar, veya diğer yapılar için imzaları taklit etmesi

Etkilenen Protokoller

Aşağıdaki protokolleri kabaca geliştirme sırasına göre değiştireceğiz. Genel dağıtım muhtemelen 2025 sonundan 2027 ortasına kadar sürecek. Ayrıntılar için aşağıdaki Öncelikler ve Dağıtım bölümüne bakın.

Tasarım

NIST FIPS 203 ve 204 standartlarını FIPS 203 FIPS 204 destekleyeceğiz. Bu standartlar CRYSTALS-Kyber ve CRYSTALS-Dilithium (3.1, 3 ve daha eski sürümler) temel alınarak oluşturulmuştur ancak bunlarla uyumlu DEĞİLDİR.

Anahtar Değişimi

Aşağıdaki protokollerde hibrit anahtar değişimini destekleyeceğiz:

Noise N iki yönlü anahtar değişimi kullanmaz ve bu nedenle hibrit şifreleme için uygun değildir.

Bu nedenle sadece hibrit şifrelemeyi destekleyeceğiz, NTCP2, SSU2 ve Ratchet için. FIPS 203 ’te belirtildiği gibi üç ML-KEM varyantını tanımlayacağız, toplam 3 yeni şifreleme türü için. Hibrit türler sadece X25519 ile kombinasyon halinde tanımlanacak.

Yeni şifreleme türleri şunlardır:

İmzalar

Aşağıdaki yapılarda PQ ve hibrit imzaları destekleyeceğiz:

FIPS 204 bölüm 3.4’te tanımlandığı gibi “deterministik” varyant yerine “korumalı” veya rastgele imzalama varyantını kullanacağız. Bu, aynı veri üzerinde bile her imzanın farklı olmasını sağlar ve yan kanal saldırılarına karşı ek koruma sağlar. Kodlama ve bağlam dahil algoritma seçimleri hakkında ek ayrıntılar için aşağıdaki uygulama notları bölümüne bakın.

Yeni imza türleri şunlardır:

Ek yük önemli olacaktır. Tipik Ed25519 hedef ve router kimlik boyutları 391 bayttır. Bunlar algoritmaya bağlı olarak 3,5x ila 6,8x artacaktır. Ed25519 imzaları 64 bayttır. Bunlar algoritmaya bağlı olarak 38x ila 76x artacaktır. Tipik imzalanmış RouterInfo, LeaseSet, yanıtlanabilir datagramlar ve imzalanmış akış mesajları yaklaşık 1KB’tır. Bunlar algoritmaya bağlı olarak 3x ila 8x artacaktır.

Yeni hedef ve router kimlik türleri dolgu içermediğinden, sıkıştırılabilir olmayacaktır. Aktarım sırasında gzip ile sıkıştırılan hedeflerin ve router kimliklerinin boyutları, algoritma türüne bağlı olarak 12 kat - 38 kat artacaktır.

Yasal Kombinasyonlar

Destination’lar için, yeni imza türleri leaseset’teki tüm şifreleme türleriyle desteklenir. Anahtar sertifikasındaki şifreleme türünü NONE (255) olarak ayarlayın.

RouterIdentity’ler için ElGamal şifreleme türü artık kullanımdan kaldırılmıştır. Yeni imza türleri yalnızca X25519 (tür 4) şifrelemesi ile desteklenmektedir. Yeni şifreleme türleri RouterAddress’lerde belirtilecektir. Anahtar sertifikasındaki şifreleme türü tür 4 olmaya devam edecektir.

Yeni Kripto Gerekli

• ML-KEM (eski adıyla CRYSTALS-Kyber) FIPS 203
• ML-DSA (eski adıyla CRYSTALS-Dilithium) FIPS 204
• SHA3-128 (eski adıyla Keccak-256) FIPS 202 Yalnızca SHAKE128 için kullanılır
• SHA3-256 (eski adıyla Keccak-512) FIPS 202
• SHAKE128 ve SHAKE256 (SHA3-128 ve SHA3-256’nın XOF uzantıları) FIPS 202

SHA3-256, SHAKE128 ve SHAKE256 için test vektörleri NIST adresinde bulunmaktadır.

Java bouncycastle kütüphanesinin yukarıdakilerin tamamını desteklediğini unutmayın. C++ kütüphane desteği OpenSSL 3.5’te mevcuttur OpenSSL .

Alternatifler

FIPS 205 (Sphincs+) desteğini sunmayacağız, ML-DSA’dan çok çok daha yavaş ve büyüktür. Yaklaşan FIPS206 (Falcon) desteğini sunmayacağız, henüz standartlaştırılmamıştır. NTRU veya NIST tarafından standartlaştırılmamış diğer PQ adaylarını desteklemeyeceğiz.

Rosenpass

Wireguard’ı (IK) saf PQ kripto için uyarlama konusunda bazı araştırma makalesi bulunmakta, ancak bu makalede birkaç açık soru var. Daha sonra, bu yaklaşım PQ Wireguard için Rosenpass Rosenpass teknik raporu olarak uygulandı.

Rosenpass, önceden paylaşılmış Classic McEliece 460896 statik anahtarları (her biri 500 KB) ve Kyber-512 (temelde MLKEM-512) geçici anahtarları ile Noise KK benzeri bir el sıkışma kullanır. Classic McEliece şifre metinleri yalnızca 188 bayt olduğu ve Kyber-512 genel anahtarları ile şifre metinleri makul boyutta olduğu için, her iki el sıkışma mesajı da standart bir UDP MTU’ya sığar. PQ KK el sıkışmasından çıkan paylaşılan anahtar (osk), standart Wireguard IK el sıkışması için girdi önceden paylaşılmış anahtar (psk) olarak kullanılır. Böylece toplamda iki tam el sıkışma vardır, biri tamamen PQ ve diğeri tamamen X25519.

XK ve IK el sıkışmalarımızı değiştirmek için bunların hiçbirini yapamayız çünkü:

• KK yapamayız, Bob’un Alice’in statik anahtarı yok
• 500KB statik anahtarlar çok büyük
• Ekstra bir gidiş-dönüş istemiyoruz

Whitepaper’da çok sayıda faydalı bilgi bulunmaktadır ve bunu fikirler ve ilham için gözden geçireceğiz. TODO.

Spesifikasyon

Ortak Yapılar

Ortak yapılar belgesindeki /docs/specs/common-structures/ bölümleri ve tabloları aşağıdaki şekilde güncelleyin:

PublicKey

Yeni Public Key türleri şunlardır:

MLKEM*_CT anahtarları gerçek anlamda public key değildir, bunlar Noise handshake işleminde Bob’dan Alice’e gönderilen “ciphertext” (şifreli metin) verisidir. Eksiksiz olması için burada listelenmiştir.

PrivateKey

Yeni Private Key türleri şunlardır:

SigningPublicKey

Yeni İmzalama Genel Anahtarı türleri şunlardır:

SigningPrivateKey

Yeni İmzalama Özel Anahtar türleri şunlardır:

İmza

Yeni imza türleri şunlardır:

Anahtar Sertifikaları

Yeni İmzalama Genel Anahtar türleri şunlardır:

Hybrid veya PQ imza türlerine sahip destinasyonlar için şifreleme türü olarak NONE (tür 255) kullanın, ancak kripto anahtarı yoktur ve 384 baytlık ana bölümün tamamı imzalama anahtarı içindir.

Hedef boyutları

İşte yeni Destination türleri için uzunluklar. Tümü için Enc türü NONE (tür 255)‘dur ve şifreleme anahtarı uzunluğu 0 olarak kabul edilir. Tüm 384 baytlık bölüm, imzalama genel anahtarının ilk kısmı için kullanılır. NOT: Bu, ECDSA_SHA512_P521 ve RSA imza türleri için spesifikasyondan farklıdır, burada kullanılmamasına rağmen destination’da 256 baytlık ElGamal anahtarını koruduk.

Dolgu yok. Toplam uzunluk 7 + toplam anahtar uzunluğudur. Anahtar sertifikası uzunluğu 4 + fazla anahtar uzunluğudur.

MLDSA44 için örnek 1319 baytlık hedef bayt akışı:

skey[0:383] 5 (932 » 8) (932 & 0xff) 00 12 00 255 skey[384:1311]

RouterIdent boyutları

İşte yeni Destination türleri için uzunluklar. Tümü için şifreleme türü X25519’dur (tür 4). X25519 genel anahtarından sonraki 352 baytlık bölümün tamamı, imzalama genel anahtarının ilk kısmı için kullanılır. Dolgu yoktur. Toplam uzunluk 39 + toplam anahtar uzunluğudur. Anahtar sertifikası uzunluğu 4 + fazla anahtar uzunluğudur.

MLDSA44 için örnek 1351 baytlık router kimlik bayt akışı:

enckey[0:31] skey[0:351] 5 (960 » 8) (960 & 0xff) 00 12 00 4 skey[352:1311]

Handshake Kalıpları

El sıkışmalar Noise Protocol el sıkışma kalıplarını kullanır.

Aşağıdaki harf eşleştirmesi kullanılır:

• e = tek kullanımlık geçici anahtar
• s = statik anahtar
• p = mesaj yükü
• e1 = tek kullanımlık geçici PQ anahtarı, Alice’den Bob’a gönderilir
• ekem1 = KEM şifreli metni, Bob’dan Alice’e gönderilir

Hibrit ileri gizlilik (hfs) için XK ve IK’ye yapılan aşağıdaki değişiklikler Noise HFS spec bölüm 5’te belirtildiği gibidir:

XK:                       XKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, p               -> e, es, e1, p
  <- e, ee, p               <- e, ee, ekem1, p
  -> s, se                  -> s, se
  <- p                      <- p
  p ->                      p ->


  IK:                       IKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, s, ss, p       -> e, es, e1, s, ss, p
  <- tag, e, ee, se, p     <- tag, e, ee, ekem1, se, p
  <- p                     <- p
  p ->                     p ->

  e1 and ekem1 are encrypted. See pattern definitions below.
  NOTE: e1 and ekem1 are different sizes (unlike X25519)

e1 deseni, Noise HFS spec bölüm 4’te belirtildiği gibi şu şekilde tanımlanmıştır:

For Alice:
  (encap_key, decap_key) = PQ_KEYGEN()

  // EncryptAndHash(encap_key)
  ciphertext = ENCRYPT(k, n, encap_key, ad)
  n++
  MixHash(ciphertext)

  For Bob:

  // DecryptAndHash(ciphertext)
  encap_key = DECRYPT(k, n, ciphertext, ad)
  n++
  MixHash(ciphertext)

ekem1 deseni, Noise HFS spec bölüm 4’te belirtildiği şekilde aşağıdaki gibi tanımlanmıştır:

For Bob:

  (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

  // EncryptAndHash(kem_ciphertext)
  ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)
  MixHash(ciphertext)

  // MixKey
  MixKey(kem_shared_key)


  For Alice:

  // DecryptAndHash(ciphertext)
  kem_ciphertext = DECRYPT(k, n, ciphertext, ad)
  MixHash(ciphertext)

  // MixKey
  kem_shared_key = DECAPS(kem_ciphertext, decap_key)
  MixKey(kem_shared_key)

Noise Handshake KDF

Sorunlar

• Handshake hash fonksiyonunu değiştirmeli miyiz? Karşılaştırmaya bakın. SHA256 PQ’ya karşı savunmasız değil, ancak hash fonksiyonumuzu yükseltmek istiyorsak, diğer şeyleri değiştirirken şimdi tam zamanı. Mevcut IETF SSH önerisi IETF taslağı SHA256 ile MLKEM768 ve SHA384 ile MLKEM1024 kullanmak. Bu öneri güvenlik değerlendirmelerinin tartışmasını içeriyor.
• 0-RTT ratchet verisi göndermeyi (LS dışında) bırakmalı mıyız?
• 0-RTT verisi göndermiyorsak ratchet’i IK’dan XK’ya değiştirmeli miyiz?

Genel Bakış

Bu bölüm hem IK hem de XK protokolleri için geçerlidir.

Hibrit handshake, Noise HFS spec içinde tanımlanmıştır. Alice’den Bob’a olan ilk mesaj, mesaj yükünden önce e1 olan encapsulation key’i içerir. Bu, ek bir statik anahtar olarak işlenir; bunun üzerinde (Alice olarak) EncryptAndHash() veya (Bob olarak) DecryptAndHash() çağrısı yapın. Ardından mesaj yükünü her zamanki gibi işleyin.

İkinci mesaj, Bob’dan Alice’a, mesaj yükünden önce ekem1 şifreli metinini içerir. Bu ek bir statik anahtar olarak değerlendirilir; (Bob olarak) EncryptAndHash() veya (Alice olarak) DecryptAndHash() çağrısı yapın. Ardından, kem_shared_key’i hesaplayın ve MixKey(kem_shared_key) çağrısı yapın. Sonra mesaj yükünü her zamanki gibi işleyin.

Tanımlanmış ML-KEM İşlemleri

FIPS 203 ’te tanımlandığı gibi kullanılan kriptografik yapı taşlarına karşılık gelen aşağıdaki fonksiyonları tanımlıyoruz.

(encap_key, decap_key) = PQ_KEYGEN()

Alice creates the encapsulation and decapsulation keys
The encapsulation key is sent in message 1.
encap_key and decap_key sizes vary based on ML-KEM variant.

(ciphertext, kem_shared_key) = ENCAPS(encap_key)

Bob calculates the ciphertext and shared key,
using the ciphertext received in message 1.
The ciphertext is sent in message 2.
ciphertext size varies based on ML-KEM variant.
The kem_shared_key is always 32 bytes.

kem_shared_key = DECAPS(ciphertext, decap_key)

Alice calculates the shared key,
using the ciphertext received in message 2.
The kem_shared_key is always 32 bytes.

Hem encap_key hem de ciphertext’in Noise handshake mesajları 1 ve 2’deki ChaCha/Poly blokları içinde şifrelendiğini unutmayın. Bunlar handshake işleminin bir parçası olarak şifresi çözülecektir.

kem_shared_key, MixHash() ile chaining key’e karıştırılır. Ayrıntılar için aşağıya bakın.

Mesaj 1 için Alice KDF

XK için: ’es’ mesaj deseni sonrasında ve payload öncesinde, şunu ekleyin:

VEYA

IK için: ’es’ mesaj deseni sonrasında ve ’s’ mesaj deseni öncesinde, şunu ekleyin:

This is the "e1" message pattern:
  (encap_key, decap_key) = PQ_KEYGEN()

  // EncryptAndHash(encap_key)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, encap_key, ad)
  n++

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext)


  End of "e1" message pattern.

  NOTE: For the next section (payload for XK or static key for IK),
  the keydata and chain key remain the same,
  and n now equals 1 (instead of 0 for non-hybrid).

Mesaj 1 için Bob KDF

XK için: ’es’ mesaj kalıbından sonra ve yükten önce, şunu ekleyin:

VEYA

IK için: ’es’ mesaj deseni sonrasında ve ’s’ mesaj deseni öncesinde, şunu ekleyin:

This is the "e1" message pattern:

  // DecryptAndHash(encap_key_section)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  encap_key = DECRYPT(k, n, encap_key_section, ad)
  n++

  // MixHash(encap_key_section)
  h = SHA256(h || encap_key_section)

  End of "e1" message pattern.

  NOTE: For the next section (payload for XK or static key for IK),
  the keydata and chain key remain the same,
  and n now equals 1 (instead of 0 for non-hybrid).

Mesaj 2 için Bob KDF

XK için: ’ee’ mesaj deseninden sonra ve payload’dan önce, şunu ekleyin:

VEYA

IK için: ’ee’ mesaj kalıbından sonra ve ‘se’ mesaj kalıbından önce, şunları ekleyin:

This is the "ekem1" message pattern:

  (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

  // EncryptAndHash(kem_ciphertext)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext)

  // MixKey(kem_shared_key)
  keydata = HKDF(chainKey, kem_shared_key, "", 64)
  chainKey = keydata[0:31]

  End of "ekem1" message pattern.

Mesaj 2 için Alice KDF

’ee’ mesaj deseninden sonra (ve IK için ‘ss’ mesaj deseninden önce), şunu ekleyin:

This is the "ekem1" message pattern:

  // DecryptAndHash(kem_ciphertext_section)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  kem_ciphertext = DECRYPT(k, n, kem_ciphertext_section, ad)

  // MixHash(kem_ciphertext_section)
  h = SHA256(h || kem_ciphertext_section)

  // MixKey(kem_shared_key)
  kem_shared_key = DECAPS(kem_ciphertext, decap_key)
  keydata = HKDF(chainKey, kem_shared_key, "", 64)
  chainKey = keydata[0:31]

  End of "ekem1" message pattern.

Mesaj 3 için KDF (yalnızca XK)

değişmedi

split() için KDF

değişmemiş

Ratchet

ECIES-Ratchet spesifikasyonunu /docs/specs/ecies/ aşağıdaki şekilde güncelleyin:

Noise tanımlayıcıları

• “Noise_IKhfselg2_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM1024_ChaChaPoly_SHA256”

1b) Yeni oturum formatı (bağlama ile)

Değişiklikler: Mevcut ratchet, statik anahtarı ilk ChaCha bölümünde ve yükü ikinci bölümde içeriyordu. ML-KEM ile artık üç bölüm bulunmakta. İlk bölüm şifreli PQ genel anahtarını içeriyor. İkinci bölüm statik anahtarı içeriyor. Üçüncü bölüm yükü içeriyor.

Şifrelenmiş format:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   New Session Ephemeral Public Key    |
  +             32 bytes                  +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +           ML-KEM encap_key            +
  |       ChaCha20 encrypted data         |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +    (MAC) for encap_key Section        +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +           X25519 Static Key           +
  |       ChaCha20 encrypted data         |
  +             32 bytes                  +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +    (MAC) for Static Key Section       +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       ChaCha20 encrypted data         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +         (MAC) for Payload Section     +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

Şifresi çözülmüş format:

Payload Part 1:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +       ML-KEM encap_key                +
  |                                       |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 2:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X25519 Static Key               +
  |                                       |
  +      (32 bytes)                       +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 3:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

Boyutlar:

1g) Yeni Oturum Yanıt formatı

Değişiklikler: Mevcut ratchet, ilk ChaCha bölümü için boş bir payload’a ve ikinci bölümde payload’a sahiptir. ML-KEM ile artık üç bölüm bulunmaktadır. İlk bölüm şifrelenmiş PQ ciphertext’ini içerir. İkinci bölümde boş bir payload bulunur. Üçüncü bölüm payload’ı içerir.

Şifrelenmiş format:

  +----+----+----+----+----+----+----+----+
  |       Session Tag   8 bytes           |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Ephemeral Public Key           +
  |                                       |
  +            32 bytes                   +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  | ChaCha20 encrypted ML-KEM ciphertext  |
  +      (see table below for length)     +
  ~                                       ~
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +  (MAC) for ciphertext Section         +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +  (MAC) for key Section (no data)      +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       ChaCha20 encrypted data         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +         (MAC) for Payload Section     +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

Şifresi çözülmüş format:

Payload Part 1:


  +----+----+----+----+----+----+----+----+
  |                                       |
  +       ML-KEM ciphertext               +
  |                                       |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 2:

  empty

  Payload Part 3:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

Boyutlar:

NTCP2

NTCP2 spesifikasyonunu /docs/specs/ntcp2/ aşağıdaki şekilde güncelleyin:

Noise tanımlayıcıları

• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM1024_ChaChaPoly_SHA256”

1) SessionRequest

Değişiklikler: Mevcut NTCP2 sadece ChaCha bölümündeki seçenekleri içeriyor. ML-KEM ile birlikte, ChaCha bölümü ayrıca şifrelenmiş PQ public key’i de içerecek.

PQ ve PQ olmayan NTCP2’nin aynı router adresi ve portu üzerinde desteklenebilmesi için, X değerinin (X25519 geçici açık anahtarı) en anlamlı bitini bunun bir PQ bağlantısı olduğunu işaretlemek için kullanırız. Bu bit, PQ olmayan bağlantılar için her zaman sıfırlanmış durumdadır.

Alice için, mesaj Noise tarafından şifrelendikten sonra ancak X’in AES gizlemesinden önce, X[31] |= 0x7f olarak ayarla.

Bob için, X’in AES gizleme çözme işleminden sonra, X[31] & 0x80’i test edin. Bit ayarlanmışsa, X[31] &= 0x7f ile temizleyin ve PQ bağlantısı olarak Noise ile şifreyi çözün. Bit temizse, her zamanki gibi PQ olmayan bağlantı olarak Noise ile şifreyi çözün.

Farklı bir router adresi ve portunda tanıtılan PQ NTCP2 için bu gerekli değildir.

Ek bilgi için, aşağıdaki Yayınlanan Adresler bölümüne bakın.

Ham içerikler:

  +----+----+----+----+----+----+----+----+
  |        MS bit set to 1 and then       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted X         |
  +             (32 bytes)                +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (MLKEM)            |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~   n = 0                               ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaChaPoly frame (options)          |
  +         32 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  ~         padding (optional)            ~
  |     length defined in options block   |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmemiştir):

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Not: PQ bağlantıları için bile, mesaj 1 seçenekler bloğundaki sürüm alanı 2 olarak ayarlanmalıdır.

Boyutlar:

2) SessionCreated

Ham içerikler:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted Y         |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (MLKEM)            |
  +   Encrypted and authenticated data    +
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |   n = 0; see KDF for associated data  |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (options)          |
  +   Encrypted and authenticated data    +
  -           32 bytes                    -
  +   k defined in KDF for message 2      +
  |   n = 0; see KDF for associated data  |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmemiş):

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Boyutlar:

3) SessionConfirmed

Değişmemiş

Anahtar Türetme Fonksiyonu (KDF) (veri aşaması için)

Değişmedi

Yayınlanmış Adresler

Tüm durumlarda, her zamanki gibi NTCP2 transport adını kullanın.

PQ olmayan, güvenlik duvarı arkasında olmayan ile aynı adres/port kullanın. Sadece bir PQ varyantı desteklenir. Router adresinde, v=2 (her zamanki gibi) ve MLKEM 512/768/1024’ü belirtmek için yeni parametre pq=[3|4|5] yayınlayın. Alice, bunun hibrit bir bağlantı olduğunu belirtmek için oturum isteğinde ephemeral anahtarın MSB’sini (key[31] & 0x80) ayarlar. Yukarıya bakın. Eski router’lar pq parametresini yok sayacak ve her zamanki gibi PQ olmayan bağlantı kuracaktır.

PQ olmayan ile farklı adres/port veya yalnızca PQ, güvenlik duvarı olmayan desteklenmiyor. Bu, PQ olmayan NTCP2 devre dışı bırakılana kadar, şu andan birkaç yıl sonrasına kadar uygulanmayacak. PQ olmayan devre dışı bırakıldığında, birden fazla PQ varyantı desteklenebilir, ancak adres başına yalnızca bir tane. Router adresinde, MLKEM 512/768/1024’ü belirtmek için v=[3|4|5] yayınla. Alice, geçici anahtarın MSB’sini ayarlamaz. Eski router’lar v parametresini kontrol edecek ve bu adresi desteklenmeyen olarak atlayacak.

Firewall’lu adresler (IP yayınlanmaz): Router adresinde, v=2 yayınlayın (her zamanki gibi). Bir pq parametresi yayınlamaya gerek yoktur.

Alice, kendi router bilgilerinde pq desteğinin reklamını yapıp yapmadığına veya aynı varyantın reklamını yapıp yapmadığına bakılmaksızın, Bob’un yayınladığı PQ varyantını kullanarak PQ Bob’a bağlanabilir.

Maksimum Dolgu

Mevcut spesifikasyonda, 1 ve 2 numaralı mesajların “makul” miktarda dolgu içermesi tanımlanmıştır, 0-31 bayt aralığı önerilmekte ve maksimum değer belirtilmemektedir.

API 0.9.68 (sürüm 2.11.0) aracılığıyla, Java I2P, PQ olmayan bağlantılar için maksimum 256 bayt padding uyguladı, ancak bu daha önce belgelenmemişti. API 0.9.69 (sürüm 2.12.0) itibariyle, Java I2P, PQ olmayan bağlantılar için MLKEM-512 ile aynı maksimum padding’i uygular. Aşağıdaki tabloya bakın.

Tanımlanan mesaj boyutunu maksimum padding olarak kullanın, yani maksimum padding PQ bağlantıları için mesaj boyutunu ikiye katlayacaktır, şu şekilde:

SSU2

SSU2 spesifikasyonunu /docs/specs/ssu2/ aşağıdaki gibi güncelleyin:

Noise tanımlayıcıları

• “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”

MLKEM-1024’ün SSU2 için desteklenmediğini unutmayın, çünkü anahtarlar standart 1500 baytlık datagram içine sığmayacak kadar büyüktür.

Uzun Başlık

Uzun başlık 32 bayttır. Bir oturum oluşturulmadan önce Token Request, SessionRequest, SessionCreated ve Retry için kullanılır. Ayrıca oturum-dışı Peer Test ve Hole Punch mesajları için de kullanılır.

Aşağıdaki mesajlarda, MLKEM-512 veya MLKEM-768’i belirtmek için uzun başlıktaki ver (sürüm) alanını 3 veya 4 olarak ayarlayın.

• (0) Oturum İsteği
• (1) Oturum Oluşturuldu
• (9) Yeniden Deneme
• (10) Token İsteği
• (11) Delik Delme

Aşağıdaki mesajlarda, MLKEM-512 veya MLKEM-768 desteklense bile, uzun başlıktaki ver (version) alanını her zamanki gibi 2 olarak ayarlayın. Uygulamalar, diğer uç bunu destekliyorsa değeri 3 veya 4 olarak da ayarlayabilir, ancak bu gerekli değildir. Uygulamalar 2-4 arası herhangi bir değeri kabul etmelidir.

• (7) Peer Test (oturum dışı mesajlar 5-7)

Tartışma: Sürüm alanını 3 veya 4 olarak ayarlamak tüm mesaj türleri için kesinlikle gerekli olmayabilir, ancak bunu yapmak desteklenmeyen kuantum sonrası bağlantılar için daha erken hata tespitine yardımcı olur. Token Request ve Retry (tip 9 ve 10) tutarlılık için 3/4 sürümlerine sahip olmalıdır. Hole Punch mesajları (tip 11) bu muameleyi gerektirmeyebilir ancak tekdüzelik için aynı kalıbı izleyeceğiz. Peer Test mesajları (tip 7) oturum dışıdır ve bir oturum başlatma niyetini göstermez.

Header şifrelemesinden önce:

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 0, 1, 7, 9, 10, or 11

  ver :: The protocol version = 2, 3, or 4 for non-PQ, MLKEM512, MLKEM768

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: 8 bytes, unsigned big endian integer

  Token :: 8 bytes, unsigned big endian integer

Kısa Başlık

değişmemiş

SessionRequest (Tip 0)

Değişiklikler: Mevcut SSU2, ChaCha bölümünde yalnızca blok verilerini içerir. ML-KEM ile birlikte, ChaCha bölümü ayrıca şifrelenmiş PQ public key’i de içerecektir.

Spoof Koruması için KDF Değişikliği: Proposal 165 [Prop165]_’te ortaya çıkan sorunları ele almak için, ancak farklı bir çözümle, Session Request için KDF’yi değiştiriyoruz. Bu sadece PQ oturumları içindir. PQ olmayan oturumlar için KDF değişmeden kalır.

// End of KDF for initial chain key (unchanged)
  // Bob static key
  // MixHash(bpk)
  h = SHA256(h || bpk);

  // Start of KDF for session request
  // NEW for PQ only
  // bhash = Bob router hash (32 bytes)
  // MixHash(bhash)
  h = SHA256(h || bhash);

  // Rest of KDF for session request, unchanged, as in SSU2 spec
  // MixHash(header)
  h = SHA256(h || header)

  ...

Ham içerikler:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |    See Header Encryption KDF          |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key n=0     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X, ChaCha20 encrypted           +
  |       with Bob intro key n=0          |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (MLKEM)     |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (payload)   |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmemiş):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |     see below for allowed blocks      |
  +----+----+----+----+----+----+----+----+

IP yükü dahil olmayan boyutlar:

MLKEM768_X25519 için minimum MTU: IPv4 için yaklaşık 1316 ve IPv6 için 1336.

SessionCreated (Tip 1)

Değişiklikler: Mevcut SSU2, ChaCha bölümünde yalnızca blok verilerini içerir. ML-KEM ile birlikte, ChaCha bölümü ayrıca şifrelenmiş PQ public key’i de içerecektir.

Ham içerik:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with derived key n=0       +
  |  See Header Encryption KDF            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       Y, ChaCha20 encrypted           +
  |       with derived key n=0            |
  +              (32 bytes)               +
  |       See Header Encryption KDF       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data (MLKEM)               |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data (payload)             |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmiyor):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

IP ek yükü dahil edilmeyerek boyutlar:

MLKEM768_X25519 için minimum MTU: IPv4 için yaklaşık 1316 ve IPv6 için 1336.

SessionConfirmed (Tip 2)

değişmedi

Veri aşaması için KDF

değişmemiş

Relay ve Peer Testi

Aşağıdaki bloklar sürüm alanları içerir. Bunlar sürüm 2’de kalacak (PQ olmayan Bob ile uyumluluk için) ve PQ için sürüm 3/4’e değişmeyecek.

• Relay İsteği
• Relay Yanıtı
• Relay Tanıtımı
• Eş Testi

PQ İmzalar: Relay blokları, Peer Test blokları ve Peer Test mesajları hepsi imza içerir. Ne yazık ki, PQ imzalar MTU’dan daha büyüktür. Şu anda Relay veya Peer Test bloklarını ya da mesajlarını birden fazla UDP paketine parçalamak için bir mekanizma bulunmamaktadır. Protokol, parçalamayı destekleyecek şekilde genişletilmelidir. Bu, belirlenecek ayrı bir öneride yapılacaktır. Bu tamamlanana kadar, Relay ve Peer Test desteklenmeyecektir.

Yayınlanan Adresler

Tüm durumlarda, SSU2 transport adını her zamanki gibi kullanın. MLKEM-1024 desteklenmez.

PQ olmayan, güvenlik duvarı arkasında olmayan ile aynı adres/port’u kullanın. Bir veya her iki PQ varyantı desteklenir. Router adresinde, v=2 (her zamanki gibi) ve MLKEM 512/768/her ikisini belirtmek için yeni pq=[3|4|3,4] parametresini yayınlayın. Eski router’lar pq parametresini görmezden gelecek ve her zamanki gibi PQ olmayan bağlantı kuracaktır.

PQ olmayan ile farklı adres/port veya sadece PQ, güvenlik duvarı olmayan DESTEKLENMEZ. Bu, PQ olmayan SSU2’nin devre dışı bırakılmasına kadar uygulanmayacaktır, bu da şu andan birkaç yıl sonra olacaktır. PQ olmayan devre dışı bırakıldığında, PQ varyantlarından biri veya her ikisi desteklenir. Router adresinde, MLKEM 512/768/her ikisini belirtmek için v=[3|4|3,4] yayınlayın. Eski router’lar v parametresini kontrol edecek ve bu adresi desteklenmeyen olarak atlayacaktır.

Firewallı adresler (yayınlanan IP yok): Router adresinde, v=2 yayınlayın (her zamanki gibi). Relay desteği için pq parametresi firewallı adreslerde MUTLAKA yayınlanmalıdır.

Alice, kendi router bilgisinde pq desteğinin reklamını yapıp yapmadığına veya aynı varyantın reklamını yapıp yapmadığına bakılmaksızın, Bob’un yayınladığı PQ varyantını kullanarak bir PQ Bob’a bağlanabilir.

MTU

MLKEM768 ile MTU’yu aşmamaya dikkat edin. SSU2 için minimum MTU 1280’dir, bu da dolgu olmadan mesaj 1’in boyutudur. Alice veya Bob’un MTU’su 1280 ise mesaj 1’e dolgu eklemeyin.

Sorunlar

Dahili olarak sürüm alanını kullanabilir ve MLKEM512 için 3, MLKEM768 için 4 kullanabiliriz.

Mesaj 1 ve 2 için, MLKEM768 paket boyutlarını 1280 minimum MTU’nun ötesine çıkaracaktır. MTU çok düşükse muhtemelen bu bağlantı için desteklenmeyecektir.

Mesaj 1 ve 2 için, MLKEM1024 paket boyutlarını 1500 maksimum MTU’nun ötesine çıkaracaktır. Bu, mesaj 1 ve 2’nin parçalanmasını gerektirecek ve büyük bir komplikasyon olacaktır. Muhtemelen yapılmayacak.

Relay ve Peer Testi: Yukarıya bakınız

Streaming

TODO: İmzalama/doğrulama işlemlerini imzayı kopyalamaktan kaçınacak şekilde tanımlamanın daha verimli bir yolu var mı?

SU3 Dosyaları

YAPILACAKLAR

IETF taslağı bölüm 8.1, uygulama karmaşıklıkları ve azalmış güvenlik nedeniyle X.509 sertifikalarında HashML-DSA kullanımını yasaklamakta ve HashML-DSA için OID atamamaktadır.

SU3 dosyalarının PQ-only imzaları için, sertifikalarda non-prehash varyantların IETF taslağında tanımlanan OID’leri kullanın. SU3 dosyalarının hibrit imzalarını tanımlamıyoruz, çünkü dosyaları iki kez hash’lememiz gerekebilir (HashML-DSA ve X2559 aynı hash fonksiyonu SHA512’yi kullanmasına rağmen). Ayrıca, bir X.509 sertifikasında iki anahtarı ve imzayı birleştirmek tamamen standart dışı olurdu.

SU3 dosyalarının Ed25519 ile imzalanmasına izin vermediğimizi ve Ed25519ph imzalamayı tanımlamış olmamıza rağmen, bunun için hiçbir zaman bir OID üzerinde anlaşmadığımızı veya kullanmadığımızı unutmayın.

Normal imza türleri SU3 dosyaları için izin verilmez; ph (prehash) varyantlarını kullanın.

Diğer Spesifikasyonlar

Yeni maksimum Destination boyutu 2599 olacaktır (base 64’te 3468).

Destination boyutları hakkında rehberlik veren diğer belgeleri güncelleyin, bunlar şunlardır:

• SAMv3
• Bittorrent
• Geliştirici yönergeleri
• Adlandırma / adres defteri / jump sunucuları
• Diğer belgeler

Ek Yük Analizi

Anahtar Değişimi

Boyut artışı (bayt):

Cloudflare tarafından bildirilen hızlar:

İmzalar

Boyut:

X25519 şifreleme türünün RI’ler için kullanıldığı varsayılarak tipik anahtar, imza, RIdent, Dest boyutları veya boyut artışları (referans için Ed25519 dahil edilmiştir). Bir Router Info, LeaseSet, yanıtlanabilir datagram’lar ve listelenen iki streaming (SYN ve SYN ACK) paketinin her biri için eklenen boyut. Mevcut Destination’lar ve LeaseSet’ler tekrarlanan dolgu içerir ve transit sırasında sıkıştırılabilir. Yeni türler dolgu içermez ve sıkıştırılamaz olacak, bu da transit sırasında çok daha yüksek boyut artışına neden olur. Yukarıdaki tasarım bölümüne bakınız.

Cloudflare tarafından bildirilen hızlar:

Güvenlik Analizi

NIST güvenlik kategorileri NIST sunumu slayt 10’da özetlenmiştir. Ön kriterler: Hibrit protokoller için minimum NIST güvenlik kategorimiz 2, PQ-only için 3 olmalıdır.

El Sıkışmalar

Bunların hepsi hibrit protokollerdir. Uygulamalar MLKEM768’i tercih etmelidir; MLKEM512 yeterince güvenli değildir.

NIST güvenlik kategorileri FIPS 203 :

İmzalar

Bu öneri hem hibrit hem de sadece PQ imza türlerini tanımlar. MLDSA44 hibrit, sadece PQ olan MLDSA65’ten daha tercih edilir. MLDSA65 ve MLDSA87 için anahtar ve imza boyutları muhtemelen bizim için çok büyük, en azından başlangıçta.

NIST güvenlik kategorileri FIPS 204 :

Tür Tercihleri

3 kripto ve 9 imza türü tanımlayıp uygulayacağımız sırada, geliştirme sürecinde performansı ölçmeyi ve artan yapı boyutlarının etkilerini daha detaylı analiz etmeyi planlıyoruz. Ayrıca diğer projelerde ve protokollerdeki gelişmeleri araştırmaya ve takip etmeye devam edeceğiz.

Bir yıl veya daha fazla geliştirme sürecinden sonra, her kullanım durumu için tercih edilen bir tür veya varsayılan ayar üzerinde karar vermeye çalışacağız. Seçim, bant genişliği, CPU ve tahmini güvenlik seviyesi arasında ödünleşimler yapmayı gerektirecektir. Tüm türler her kullanım durumu için uygun olmayabilir veya izin verilmeyebilir.

Ön tercihler aşağıdaki gibidir, değişikliğe tabidir:

Şifreleme: MLKEM768_X25519

İmzalar: MLDSA44_EdDSA_SHA512_Ed25519

Ön kısıtlamalar aşağıdaki gibidir, değişikliğe tabidir:

Şifreleme: MLKEM1024_X25519, SSU2 için izin verilmiyor

İmzalar: MLDSA87 ve hibrit varyantı muhtemelen çok büyük; MLDSA65 ve hibrit varyantı çok büyük olabilir

Uygulama Notları

Kütüphane Desteği

Bouncycastle, BoringSSL ve WolfSSL kütüphaneleri artık MLKEM ve MLDSA’yı destekliyor. OpenSSL desteği 8 Nisan 2025’teki 3.5 sürümlerinde olacak OpenSSL .

Java I2P tarafından uyarlanan southernstorm.com Noise kütüphanesi hibrit el sıkışmalar için ön destek içeriyordu, ancak kullanılmadığı için kaldırdık; bunu geri ekleyip Noise HFS spec ile eşleşecek şekilde güncellememiz gerekecek.

İmzalama Varyantları

FIPS 204 bölüm 3.4’te tanımlandığı gibi, “deterministik” varyant değil, “hedge edilmiş” veya rastgeleleştirilmiş imzalama varyantını kullanacağız. Bu, aynı veri üzerinde bile her imzanın farklı olmasını sağlar ve yan kanal saldırılarına karşı ek koruma sunar. FIPS 204 , “hedge edilmiş” varyantın varsayılan olduğunu belirtse de, bu çeşitli kütüphanelerde geçerli olabilir veya olmayabilir. Uygulayıcılar, imzalama için “hedge edilmiş” varyantın kullanıldığından emin olmalıdır.

Normal imzalama sürecini (Pure ML-DSA Signature Generation olarak adlandırılır) kullanıyoruz, bu süreç mesajı dahili olarak 0x00 || len(ctx) || ctx || message şeklinde kodlar, burada ctx 0x00..0xFF boyutunda isteğe bağlı bir değerdir. Herhangi bir isteğe bağlı bağlam kullanmıyoruz. len(ctx) == 0. Bu süreç FIPS 204 Algoritma 2 adım 10 ve Algoritma 3 adım 5’te tanımlanmıştır. Yayınlanan bazı test vektörlerinin mesajın kodlanmadığı bir mod ayarlaması gerektirebileceğini unutmayın.

Güvenilirlik

Boyut artışı, NetDB depolamaları, streaming el sıkışmaları ve diğer mesajlar için çok daha fazla tunnel fragmentasyonuna neden olacaktır. Performans ve güvenilirlik değişikliklerini kontrol edin.

Yapı Boyutları

Router bilgilerinin ve leaseSet’lerin bayt boyutunu sınırlayan herhangi bir kodu bulun ve kontrol edin.

NetDB

RAM’de veya diskte depolanan maksimum LS/RI sayısını gözden geçir ve muhtemelen azalt, depolama artışını sınırlamak için. floodfill’ler için minimum bant genişliği gereksinimlerini artır?

Ratchet

Paylaşımlı Tunnel’lar

Aynı tunnel’lar üzerinde birden fazla protokolün otomatik sınıflandırılması/tespiti, mesaj 1’in (New Session Message) uzunluk kontrolüne dayalı olarak mümkün olmalıdır. MLKEM512_X25519 örnek olarak alındığında, mesaj 1 uzunluğu mevcut ratchet protokolünden 816 bayt daha büyüktür ve minimum mesaj 1 boyutu (yalnızca DateTime payload dahil) 919 bayttır. Mevcut ratchet ile çoğu mesaj 1 boyutu 816 bayttan daha az payload’a sahiptir, bu nedenle hibrit olmayan ratchet olarak sınıflandırılabilirler. Büyük mesajlar muhtemelen nadiren görülen POST’lardır.

Bu nedenle önerilen strateji şudur:

• Eğer mesaj 1, 919 bayttan küçükse, mevcut ratchet protokolüdür.
• Eğer mesaj 1, 919 bayt veya daha büyükse, muhtemelen MLKEM512_X25519’dur. Önce MLKEM512_X25519’u deneyin, başarısız olursa mevcut ratchet protokolünü deneyin.

Bu, daha önce aynı hedefte ElGamal ve ratchet’i desteklediğimiz gibi, aynı hedefte standart ratchet ve hibrit ratchet’i verimli bir şekilde desteklememizi sağlamalıdır. Dolayısıyla, aynı hedef için çift protokol desteği sunamasaydık olacağından çok daha hızlı bir şekilde MLKEM hibrit protokolüne geçiş yapabiliriz, çünkü mevcut hedeflere MLKEM desteği ekleyebiliriz.

Gerekli desteklenen kombinasyonlar şunlardır:

• X25519 + MLKEM512
• X25519 + MLKEM768
• X25519 + MLKEM1024

Aşağıdaki kombinasyonlar karmaşık olabilir ve desteklenmesi ZORUNLU DEĞİLDİR, ancak implementasyon-bağımlı olarak desteklenebilir:

• Birden fazla MLKEM
• ElG + bir veya daha fazla MLKEM
• X25519 + bir veya daha fazla MLKEM
• ElG + X25519 + bir veya daha fazla MLKEM

Aynı hedef üzerinde birden fazla MLKEM algoritmasını (örneğin, MLKEM512_X25519 ve MLKEM_768_X25519) desteklemeye çalışmayabiliriz. Sadece birini seçin; ancak bu, tercih edilen bir MLKEM varyantı seçmemize bağlıdır, böylece HTTP istemci tunnel’ları birini kullanabilir. Uygulama bağımlıdır.

Aynı hedef üzerinde üç algoritmayı (örneğin X25519, MLKEM512_X25519 ve MLKEM769_X25519) desteklemeye çalışabiliriz. Sınıflandırma ve yeniden deneme stratejisi çok karmaşık olabilir. Yapılandırma ve yapılandırma arayüzü çok karmaşık olabilir. Uygulamaya bağlıdır.

Muhtemelen aynı hedef üzerinde ElGamal ve hibrit algoritmaları desteklemeye ÇALIŞMAYACAĞIZ. ElGamal eskimiştir ve ElGamal + hibrit sadece (X25519 yok) pek mantıklı değildir. Ayrıca, ElGamal ve Hibrit Yeni Oturum Mesajları her ikisi de büyüktür, bu nedenle sınıflandırma stratejileri genellikle her iki şifre çözme işlemini de denemek zorunda kalacaktır, bu da verimsiz olacaktır. Uygulamaya bağlıdır.

İstemciler aynı tunnel’lar üzerinde X25519 ve hibrit protokoller için aynı veya farklı X25519 statik anahtarları kullanabilirler, bu implementasyon-bağımlıdır.

İleri Gizlilik

ECIES spesifikasyonu, New Session Message yükünde Garlic Messages’a izin verir, bu da ilk streaming paketinin (genellikle bir HTTP GET) istemcinin leaseset’i ile birlikte 0-RTT teslimatını sağlar. Ancak, New Session Message yükü forward secrecy’ye sahip değildir. Bu öneri ratchet için gelişmiş forward secrecy’yi vurguladığından, implementasyonlar streaming yükünü veya tam streaming mesajını ilk Existing Session Message’a kadar erteleyebilir veya ertelemelidir. Bu, 0-RTT teslimatın pahasına olacaktır. Stratejiler ayrıca trafik türüne veya tunnel türüne, ya da örneğin GET vs. POST’a bağlı olabilir. Implementasyon-bağımlıdır.

Yeni Oturum Boyutu

MLKEM, MLDSA veya aynı hedefte her ikisi birden, yukarıda açıklandığı gibi New Session Message boyutunu dramatik şekilde artıracaktır. Bu, 1024 bayt tunnel mesajlarına parçalanması gereken tunnel’lar aracılığıyla New Session Message teslimatının güvenilirliğini önemli ölçüde azaltabilir. Teslimat başarısı, parça sayısının üstelsel oranıyla doğru orantılıdır. Uygulamalar, 0-RTT teslimat pahasına mesaj boyutunu sınırlamak için çeşitli stratejiler kullanabilir. Uygulamaya bağlıdır.

NTCP2

Bunun hibrit bir bağlantı olduğunu belirtmek için oturum isteğinde geçici anahtarın MSB’sini (key[31] & 0x80) ayarlıyoruz. Bu, aynı port üzerinde hem standart NTCP hem de hibrit NTCP çalıştırmamıza olanak tanır. Yalnızca bir hibrit varyant desteklenecek ve router adresinde duyurulacaktır. Örneğin, v=2,3 veya v=2,4 veya v=2,5.

Gizleme

Alice olarak, PQ bağlantısı için, obfuscation öncesinde X[31] |= 0x80 ayarlayın. Bu, X’i geçersiz bir X25519 public key yapar. Obfuscation sonrasında, AES-CBC bunu rastgele hale getirir. Obfuscation sonrasında X’in MSB’si rastgele olacaktır.

Bob olarak, de-obfuscation (gizleme kaldırma) işleminden sonra (X[31] & 0x80) != 0 olup olmadığını test edin. Eğer öyleyse, bu bir PQ bağlantısıdır.

NTCP2-PQ için gereken minimum router sürümü henüz belirlenmemiştir.

Not: Tür kodları yalnızca dahili kullanım içindir. Router’lar tür 4 olarak kalacak ve destek router adreslerinde belirtilecektir.

SSU2

Uzun başlıkta versiyon alanını kullanıyoruz ve MLKEM512 için 3, MLKEM768 için 4 olarak ayarlıyoruz. Adreste v=2,3,4 yeterli olacaktır.

SSU2’nin MLDSA-imzalı RI’yi birden fazla pakete (6-8?) bölünmüş şekilde işleyebilidiğini kontrol edin ve doğrulayın.

Not: Tip kodları yalnızca dahili kullanım içindir. Router’lar tip 4 olarak kalacak ve destek router adreslerinde belirtilecektir.

Router Uyumluluğu

Transport İsimleri

Her durumda, NTCP2 ve SSU2 transport isimlerini her zamanki gibi kullanın.

Router Şifreleme Türleri

Değerlendirmemiz gereken birkaç alternatifimiz var:

Tip 5/6/7 Router’lar

Önerilmez. Yalnızca yukarıda listelenen ve router türüyle eşleşen yeni aktarımları kullanın. Eski router’lar bağlanamaz, üzerinden tunnel kuramaz veya netDb mesajları gönderemez. Varsayılan olarak etkinleştirmeden önce hata ayıklama ve destek sağlanması için birkaç sürüm döngüsü alır. Aşağıdaki alternatiflere göre kullanıma sunumunu bir yıl veya daha fazla uzatabilir.

Tip 4 Router’lar

Önerilen. PQ, X25519 statik anahtarını veya N handshake protokollerini etkilemediğinden, router’ları tip 4 olarak bırakabilir ve sadece yeni transport’ları duyurabiliriz. Eski router’lar yine de bağlanabilir, tunnel’lar kurabilir veya netDb mesajları gönderebilir.

Öneriler

MLKEM-768, güvenlik ve anahtar uzunluğu arasındaki en iyi denge olarak Ratchet, NTCP2 ve SSU2 için önerilir.

Router İmza Türleri

Tip 12-17 Router’lar

Eski router’lar RI’ları doğrular ve bu nedenle bağlanamaz, üzerinden tunnel oluşturamaz veya netDb mesajları gönderemez. Varsayılan olarak etkinleştirmeden önce hata ayıklama ve destek sağlama için birkaç sürüm döngüsü gerekir. Enc. type 5/6/7 dağıtımıyla aynı sorunlar olur; yukarıda listelenen type 4 enc. type dağıtım alternatifine göre dağıtımı bir yıl veya daha fazla uzatabilir.

Alternatif yok.

LS Şifreleme Türleri

Tip 5-7 LS Anahtarları

Bunlar, eski tip 4 X25519 anahtarları olan LS’de bulunabilir. Eski router’lar bilinmeyen anahtarları göz ardı eder.

Hedefler birden fazla anahtar türünü destekleyebilir, ancak yalnızca her anahtarla mesaj 1’in deneme şifre çözmelerini yaparak. Ek yük, her anahtar için başarılı şifre çözme sayılarını tutarak ve en çok kullanılan anahtarı önce deneyerek hafifletilebilir. Java I2P aynı hedef üzerinde ElGamal+X25519 için bu stratejiyi kullanır.

Hedef İmza Türleri

Tip 12-17 Hedefler

Router’lar leaseSet imzalarını doğrular ve bu nedenle tip 12-17 hedefler için bağlantı kuramaz veya leaseSet alamaz. Varsayılan olarak etkinleştirmeden önce hata ayıklama ve destek sağlanması için birkaç sürüm döngüsü gerekir.

Alternatif yok.

Öncelikler ve Dağıtım

En değerli veriler, ratchet ile şifrelenmiş uçtan uca trafiklerdir. Tünel atlamaları arasındaki harici bir gözlemci olarak, bu veriler iki kez daha şifrelenir: tünel şifrelemesi ve taşıma şifrelemesi ile. OBEP ve IBGW arasındaki harici bir gözlemci olarak, yalnızca bir kez daha şifrelenir: taşıma şifrelemesi ile. Bir OBEP veya IBGW katılımcısı olarak, ratchet tek şifrelemedir. Ancak, tüneller tek yönlü olduğundan, ratchet el sıkışmasındaki her iki mesajı yakalamak, tüneller aynı router üzerinde OBEP ve IBGW ile kurulmadıkça, işbirlikçi router’lar gerektirir.

Şu anda en endişe verici PQ tehdit modeli, trafiği bugün depolayıp bundan yıllar sonra şifresini çözmek (ileri gizlilik). Hibrit bir yaklaşım bunu koruyabilir.

Kimlik doğrulama anahtarlarını makul bir süre içinde (örneğin birkaç ay) kırma ve ardından kimliğe bürünme veya neredeyse gerçek zamanlı şifre çözme şeklindeki PQ tehdit modeli çok daha uzak bir gelecekte mi? Ve işte o zaman PQC statik anahtarlara geçiş yapmak isteyeceğiz.

Yani, en erken PQ tehdit modeli OBEP/IBGW’nin trafiği daha sonra şifre çözme için depolamasıdır. Önce hibrit ratchet’i uygulamamız gerekiyor.

Ratchet en yüksek önceliğe sahiptir. Transport’lar sonraki sırada gelir. İmzalar en düşük önceliğe sahiptir.

İmza dağıtımı da şifreleme dağıtımından bir yıl veya daha fazla geç olacaktır, çünkü geriye dönük uyumluluk mümkün değildir. Ayrıca, endüstride MLDSA benimsenimesi CA/Browser Forum ve Sertifika Otoriteleri tarafından standardize edilecektir. CA’lar önce donanım güvenlik modülü (HSM) desteğine ihtiyaç duymaktadır ve bu şu anda mevcut değildir CA/Browser Forum . CA/Browser Forum’un kompozit imzaları destekleme veya zorunlu kılma dahil olmak üzere belirli parametre seçimlerinde kararları yönlendirmesini bekliyoruz IETF draft .

Geçiş

Aynı tunnel’larda hem eski hem de yeni ratchet protokollerini destekleyemezsek, geçiş çok daha zor olacaktır.

X25519’da yaptığımız gibi, kanıtlanması için birini-sonra-diğerini deneyebilmeliyiz.

Sorunlar

• Noise Hash seçimi - SHA256 ile devam mı yoksa yükseltme mi? SHA256’nın 20-30 yıl daha iyi olması gerekiyor, PQ tarafından tehdit edilmiyor, NIST sunumuna ve NCCOE sunumuna bakın. Eğer SHA256 kırılırsa daha kötü sorunlarımız olur (netdb).
• NTCP2 ayrı port, ayrı router adresi
• SSU2 relay / peer test
• SSU2 sürüm alanı
• SSU2 router adres sürümü

Referanslar

• CABFORUM
• Choosing-Hash
• CLOUDFLARE
• COMMON
• COMPOSITE-SIGS
• ECIES
• FORUM
• FIPS202
• FIPS203
• FIPS204
• FIPS205
• MLDSA-OIDS
• NIST-PQ
• NIST-PQ-UPDATE
• NIST-PQ-END
• NIST-VECTORS
• Noise
• Noise-Hybrid
• NSA-PQ
• NTCP2
• OPENSSL
• Prop165
• PQ-WIREGUARD
• RFC-2104
• Rosenpass
• Rosenpass-Whitepaper
• SSH-HYBRID
• SSU2
• TLS-HYBRID