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:

Bu nedenle hem PQ-only hem de hibrit imzaları destekleyeceğiz. FIPS 204 ’te tanımlandığı gibi üç ML-DSA varyantını, Ed25519 ile üç hibrit varyantı ve yalnızca SU3 dosyaları için prehash ile üç PQ-only varyantını tanımlayacağız, toplamda 9 yeni imza tipi. Hibrit tipler yalnızca Ed25519 ile kombinasyon halinde tanımlanacak. SU3 dosyaları hariç, pre-hash varyantları (HashML-DSA) DEĞİL standart ML-DSA kullanacağız.

Yeni imza türleri şunlardır:

X.509 sertifikaları ve diğer DER kodlamaları, IETF taslağında tanımlanan kompozit yapıları ve OID’leri kullanacaktı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.

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.

Yasal Kombinasyonlar

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.

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

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

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 .

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.

Alternatifler

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

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ü:

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

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

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

Spesifikasyon

Ortak Yapılar

Yeni Public Key türleri şunlardır:

PublicKey

Hibrit public key’ler X25519 anahtarıdır. KEM public key’ler Alice’ten Bob’a gönderilen geçici PQ anahtarıdır. Kodlama ve byte sırası FIPS 203 ’te tanımlanmıştır.

Yeni Private Key türleri şunlardır:

PrivateKey

Hibrit özel anahtarlar X25519 anahtarlarıdır. KEM özel anahtarları yalnızca Alice içindir. KEM kodlaması ve bayt sırası FIPS 203 ’te tanımlanmıştır.

SigningPublicKey

Hibrit imzalama public key’leri, IETF taslağında olduğu gibi Ed25519 key’ini takip eden PQ key’idir. Kodlama ve byte sırası FIPS 204 ’te tanımlanmıştır.

SigningPrivateKey

Hibrit imzalama özel anahtarları, IETF taslağında olduğu gibi Ed25519 anahtarının ardından PQ anahtarının gelmesiyle oluşur. Kodlama ve bayt sırası FIPS 204 ’te tanımlanmıştır.

İmzalama özel anahtarları asla kabloya gönderilmez. Uygulamalar, genişletilmiş çok kilobaytlık özel anahtar yerine COMPOSITE-SIGS belgesinde önerildiği gibi 32 bitlik tohumu saklamayı tercih edebilir. Bu, uygulamaya bağlıdır.

İmza

Yeni İmza türleri şunlardır:

Anahtar Sertifikaları

Hibrit imzalama public key’leri, IETF taslağında olduğu gibi Ed25519 key’ini takip eden PQ key’idir. Kodlama ve byte sırası FIPS 204 ’te tanımlanmıştır.

Hibrit veya PQ imza türlerine sahip hedefler için şifreleme türü olarak NONE (tür 255) kullanın, ancak bir şifreleme 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.

Doldurma yok. Toplam uzunluk 7 artı toplam anahtar uzunluğudur. Anahtar sertifikası uzunluğu 4 artı fazladan 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 1351 baytlık örnek yönlendirici kimliği bayt akışı:

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

Bileşik İmzalar

Aşağıdaki şekilde, bileşik imza algoritmaları için yeni bir spesifikasyon ekleyin: Bileşik hibrit imzalar, COMPOSITE-SIGS belgesinde tanımlandığı gibidir. Ancak her zamanki gibi, I2P içindeki ortak anahtarlar ve imzalar DER kodlamalarını içermez.

Bileşik imzalar her zaman ön-havlama kullanır, böylece potansiyel olarak büyük iletilerin iki kez işlenmesine gerek kalmaz. Bu, MLDSA algoritmasının dışındadır ve standart MLDSA kullanıyoruz, HashML-DSA değil.

İmzalama Algoritması

  M = message
  Prefix = "CompositeAlgorithmSignatures2025" (32 bytes, not null terminated)
  Label = (30 bytes, not null terminated), one of:
          "COMPSIG-MLDSA44-Ed25519-SHA512"
          "COMPSIG-MLDSA65-Ed25519-SHA512"
          "COMPSIG-MLDSA87-Ed25519-SHA512"  // not in [COMPOSITE-SIGS]
  ctx = "" (0 bytes)
  len(ctx) = 0  (1 byte)
  PH(M) = SHA512(M) (64 bytes)


  Compute a hash of the message prepended as follows:

  M' = Prefix || Label || len(ctx) || ctx || PH( M )

  M' length is 127 bytes.

  Sign the prehashed message M':

  signature = MLDSA_SIGN(M') || Ed25519_SIGN(M')

Doğrulama Algoritması

İmzalama algoritmasıyla aynı. İmzalardan herhangi biri başarısız olursa başarısız olur.

  M' = as above

  signature = MLDSA_VERIFY(M') && Ed25519_VERIFY(M')

Sorunlar

COMPOSITE-SIGS , güvenlik gücündeki uyumsuzluk nedeniyle MLDSA87 + Ed25519 kombinasyonunu tanımlamaz. SHAKE256/64’ü önbellekleme (prehash) fonksiyonu olarak kullanarak MLDSA87 + Ed448 kombinasyonunu tanımlar. Bu öneri, şu anda Ed448’i desteklemememiz nedeniyle, bu kombinasyonu şu an içermemektedir.

Handshake Kalıpları

El sıkışmalar, Noise Protocol el sıkışma desenlerini 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’da yapılan aşağıdaki değişiklikler Noise HFS spec belgesinin 5. bölümünde 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 belgesinin 4. bölümünde belirtildiği gibi aşağıdaki şekilde tanımlanı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 deseninin tanımı, Noise HFS spec bölüm 4’te belirtildiği gibi aşağıdaki gibidir:

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 protokollerine uygulanır.

Hibrit el sıkışma, Noise HFS spec içinde tanımlanmıştır. Alice’den Bob’a giden ilk mesaj, mesaj yükünden önce e1, yani kapsülleme anahtarını içerir. Bu, ek bir statik anahtar olarak ele alınır; bunun üzerinde EncryptAndHash() (Alice olarak) veya DecryptAndHash() (Bob olarak) fonksiyonunu çalıştırın. Ardından mesaj yükü, normal şekilde işlenir.

İ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

Kullanılan kriptografik yapı taşlarına karşılık gelen ve FIPS 203 belgesinde tanımlanan aşağıdaki fonksiyonları tanımlarız.

(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) = KAPSÜLLEME(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(sifreli_metin, decap_anahtari)

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

encap_key ve şifreli metnin, Gürültü el sıkışma mesajları 1 ve 2’deki ChaCha/Poly bloklarının içinde şifrelendiğine dikkat edin. Bu değerler, el sıkışma sürecinin bir parçası olarak çö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 deseninden 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:
  (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 deseninden 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 yükten ö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.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

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.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

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

değişmedi

split() için KDF

değişmedi

Ratchet

ECIES-Ratchet spesifikasyonunu şu şekilde güncelleyin: /docs/specs/ecies/

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ünde boş bir yük taşır ve ikinci bölümde yükü taşır. ML-KEM ile artık üç bölüm vardır. İlk bölüm şifreli PQ şifreli metnini içerir. İkinci bölüm boş bir yük taşır. Üçüncü bölüm yükü taşır.

Ş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: Geçerli NTCP2 yalnızca tek bir ChaCha bölümündeki seçenekleri içerir. ML-KEM ile, seçeneklerden önce şifrelenmiş PQ genel anahtarını içeren yeni bir ChaCha bölümü eklenecek.

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 encrypted data (MLKEM)   |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~                                       ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 1                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     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:

Ham içerikler:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted Y         |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (MLKEM)     |
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  +   k defined in KDF for message 2      +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Boyutlar:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  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şmemiş

Yayınlanmış Adresler

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

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.

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.

Maksimum Dolgu

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 spesifikasyonunu /docs/specs/ssu2/ aşağıdaki gibi güncelleyin:

SSU2

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.

Noise tanımlayıcıları

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

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.

Uzun Başlık

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.

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.

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

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.

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

Header şifrelemesinden önce:

değişmemiş

  +----+----+----+----+----+----+----+----+
  |      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şmedi

SessionRequest (Tip 0)

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.

Ham içerikler:

// 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          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (payload)   |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 1                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

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

  +----+----+----+----+----+----+----+----+
  |      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.

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

SessionCreated (Tip 1)

Ham içerik:

Ham içerikler:

  +----+----+----+----+----+----+----+----+
  |  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 encrypted data (MLKEM)     |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (payload)   |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Boyutlar:

  +----+----+----+----+----+----+----+----+
  |      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 yükü dahil olmayan boyutlar:

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

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.

SessionConfirmed (Tip 2)

değişmedi

Veri aşaması için KDF

değişmedi

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

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

Yayınlanmış Adresler

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.

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.

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.

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.

MTU

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

Streaming

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.

SU3 Dosyaları

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

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

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.

Diğer Spesifikasyonlar

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.

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

Ek Yük Analizi

Anahtar Değişimi

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

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

İmzalar

Boyutlar

Cloudflare tarafından bildirilen hızlar:

Hızlar

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

Güvenlik Analizi

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.

El Sıkışmalar

Cloudflare tarafından bildirilen hızlar:

Java’da ön test sonuçları:

İmzalar

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.

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

Tür Tercihleri

NIST güvenlik kategorileri FIPS 203 :

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 :

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

Uygulama Notları

Kütüphane Desteği

İmzalar: MLDSA44_EdDSA_SHA512_Ed25519

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

İmzalama Varyantları

Ş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

Güvenilirlik

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 .

Yapı Boyutları

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.

NetDB

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.

Ratchet

Sorunlar

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.

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.

• 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.

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

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?

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

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.

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

Bu nedenle önerilen strateji şudur:

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:

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

Paylaşımlı Tunnel’lar

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.

İleri Gizlilik

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.

NTCP2

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.

Yeni Oturum Boyutu

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

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.

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.

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

SSU2

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.

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.

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

Router Uyumluluğu

Transport İsimleri

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

Router Şifreleme Türleri

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.

Gizleme

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

Tip 5/6/7 Router’lar

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

Tip 4 Router’lar

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

Router İmza Türleri

Öneriler

Değerlendirmemiz gereken birkaç alternatifimiz var:

Ö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.

LS Şifreleme Türleri

Tip 12-17 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.

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

Hedef İmza Türleri

Tip 5-7 LS Anahtarları

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.

Ö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.

Öncelikler ve Dağıtım

Alternatif yok.

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.

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.

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.

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.

I2P’de MLDSA imza desteği, standart kuruluşlarının algoritmaları seçmesi, olası olarak anahtar ve/veya imza boyutlarını azaltması ve sektör benimsemesini teşvik etmesi beklenildiği için 2027’nin sonuna veya 2028’e kadar askıya alınmıştır. Bkz. CABFORUM , COMPOSITE-SIGS , ve PLANTS . Ayrıca, MLDSA’nın sektörde benimsenmesi IETF, CA/Tarayıcı Forumu ve Sertifika Yetkilileri tarafından standartlaştırılacaktır. Sertifika Yetkililerinin öncelikle donanım güvenlik modülü (HSM) desteğine ihtiyacı var, ancak bu destek şu anda mevcut değil CA/Browser Forum . IETF ve CA/Tarayıcı Forumu’nun, bileşik imzaların desteklenip desteklenmemesi de dahil olmak üzere belirli parametre seçimleri üzerine kararlar vermesini bekliyoruz COMPOSITE-SIGS .

Geçiş

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 .

Sorunlar

SHA256, kuantum sonrası tehditlerle karşı karşıya kalmadan başka 20-30 yıl kullanılabilir olmalıdır. Bkz. NIST sunumu ve NCCOE sunumu . SHA256 kırılırsa, daha ciddi sorunlarla karşılaşırız (netDb).

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