3.1 Hassas İleti Kümesi
Bu protokol, bant genişliği sınırları altında sağlam sürekli anahtar anlaşması sağlamak üzere tasarlanmıştır. Anahtar anlaşmasına ulaşmak için çok sayıda iletinin geçirilmesi gerektiğinden, bu protokolün sağladığı önemli güvenlik ölçütü "bir ele geçirilme durumunda, iyileşme gerçekleşmeden önce kaç ileti geçer?" sorusudur. Buna hassas ileti kümesi diyoruz.
Hassas ileti kümesinin boyutu protokolün içsel bir özelliği değildir. ML-KEM Braid için, verilen parça boyutu ve KEM seçimiyle hassas ileti kümesinin mümkün olan en küçük boyutu hesaplanabilir; ancak bu kümenin en büyük boyutu sınırsızdır: Bob Alice'e hiç yanıt vermez ama Alice ileti göndermeye devam ederse, oturumları hiçbir zaman iyileşmez ve Alice'in tüm iletileri hassas olacaktır.
Nitekim [3]'te gösterildiği gibi, bir SCKA protokolü için hassas ileti kümesinin boyutu protokol katılımcılarının ileti gönderme davranışına bağlıdır. Çevrimiçi olan ve hızlı sohbet eden iki taraf, örneğin bir Signal sohbetinde birincil cihazlarını kullanan iki taraf, genellikle sık sık çevrimdışı olan masaüstü cihazlardaki iki taraf arasındaki konuşmaya kıyasla daha küçük bir hassas ileti kümesine sahip olacaktır.
ML-KEM Braid protokolü, gerçekçi güvenli mesajlaşma senaryolarının geniş bir aralığında küçük hassas ileti kümeleri sağlamak üzere seçilmiştir; ancak çok özel ileti gönderme davranışlarına sahip uygulamalarda protokol tasarımcıları, farklı bir SCKA protokolünün daha iyi güvenlik sağlayıp sağlamayacağını değerlendirmelidir.
3.2 Alternatif KEM'ler
Bu protokol ML-KEM'i belirtildiği şekilde kullanır; ancak ML-KEM'in Fujisaki-Okamoto dönüşümünün sağladığı IND-CCA güvenliğinin, bunun veya ilgili SCKA protokollerinin güvenliğini kanıtlamak için gerekli olmadığını not ederiz. [8]'de bu gerçek akılda tutularak bir IND-CPA "Ratcheting KEM" tasarlanmıştır ve bu, şifreli metnin büyük bir bölümünün gelecekteki bir tur için açık anahtar olarak yeniden kullanılmasına izin vererek bant genişliği maliyetlerini düşürür. Cırcırlı KEM iyileştirmesi olmasa bile, bu protokol tarafların kapsülleme anahtarı tohumunu belirlemek için paylaşılan oturum durumlarını kullanmaları ve ardından ML-KEM'in iç IND-CPA Public Key Encryption (PKE) işlevini kullanmalarıyla daha verimli hâle getirilebilir. Bu yalnızca ileti boyutlarını az miktarda küçültmekle kalmaz, "header" gönderimini atlamamıza ve anahtar üretmek için gereken gidiş-dönüş sayısını azaltmamıza da imkân tanır. Bu, özellikle iletişimin dengesiz olduğu, örneğin bir tarafın cihazının uzun süre çevrimdışı kaldığı durumlarda büyük fayda sağlayabilir.
Alternatif KEM'ler veya daha genel olarak verimli cırcırlama için tasarlanmış IND-CPA PKE düzenleri, ML-KEM ile aynı bağlama özelliklerine sahip olmayabilir. [9] ve [10]'da görüldüğü üzere bu bağlama özellikleri, daha üst düzey protokollerin güvenliğini etkileyebilir. Bu protokolün alternatif KEM kullanan bir varyantını kullanan geliştiriciler, bu bağlama özelliklerinin daha üst düzey protokollerindeki güvenlik etkilerini değerlendirmelidir.
3.3 İsteğe bağlı iç doğrulama
Üstbilgi ve şifreli metin iletilerine eklenen authenticator nesneleri ve MAC'ler, her epoch başına 64 bayt iletme maliyeti karşılığında ML-KEM Braid iletileri ve çıktıları için bağımsız özgünlük güvenceleri sağlar.
Eğer bu protokol, doğrulama sağlayan Double Ratchet [2] gibi daha üst düzey bir protokole entegre edilirse, protokol iletileri özgünlüğü oradan türetebilir ve ML-KEM Braid protokolünün iç doğrulaması kaldırılabilir.
3.4 Bant genişliği sınırları, ileti boyutları ve PCS hızı
Hassas ileti kümesinin boyutu protokol katılımcılarının fiilî ileti gönderme davranışına bağlı olsa da, daha büyük parçalar gönderirsek anahtar anlaşmasının ve dolayısıyla nihai iyileşmenin daha hızlı gerçekleşeceğini görmek kolaydır.
Parça boyutu 32 iken, ML-KEM 768 kullanıldığında, bir header göndermek için 3 iletiye, ct1 göndermek için 30 iletiye, ek_vector göndermek için 36 iletiye ve MAC'iyle birlikte ct2 göndermek için 5 iletiye ihtiyaç duyarız. Parça boyutunu 64'e iki katına çıkarsaydık bu sayılar yarıya inerdi (yukarı yuvarlamayla) ve ideal koşullar altında iyileşme neredeyse iki kat hızlanırdı. Ancak tarafların, Signal'in bağlı cihazlarında yaygın olduğu gibi, belirli süreler çevrimdışı kaldığı durumlarda, [3]'te görüldüğü üzere daha büyük parçaların faydaları daha az belirgin hâle gelir. Bant genişliği sınırının iki katına çıkması birçok gerçekçi durumda PCS iyileşme hızını belirgin biçimde artırır; ancak iyileşme hızının iki katına çıkmasına yol açmaz. Bant genişliği kullanımı ile PCS hızı arasındaki ödünleşme değerlendirilirken hem istemci gereksinimleri hem de istemci ileti gönderme davranışı dikkate alınmalıdır.
Katı bant genişliği sınırlarının varlığında, protokol iletilerini kodlamak için sıkı bir ikili biçim kullanılır ve bu biçim genel amaçlı bir biçime göre birkaç bayt tasarruf sağlarsa, bu baytlar daha büyük parçalar göndermek ve PCS'yi hızlandırmak için kullanılabilir.
3.5 Kodlayıcı alan boyutu
İlke olarak kodlayıcıları sınırsız bir kod sözcüğü akışı üretiyormuş gibi düşünsek de, pratikte önerdiğimiz kodlayıcı tekrar etmeden önce sonlu sayıda farklı kod sözcüğü üretir. Bu, ağ denetimine sahip bir saldırganın protokolün ilerlemesini önlemek için iki tarafa tam bir hizmet reddi saldırısı uygulamak zorunda olmadığı anlamına gelir: sonuçta kod sözcüklerinin tekrar etmesi gerekir ve tekrar eden kod sözcüklerine sahip iletilerin geçmesine izin verebilirler.
Bunun iç nedeni, kodlamanın sonlu bir alan üzerinde polinom enterpolasyonu kullanılarak uygulanmasıdır ve farklı kod sözcüklerinin sayısı alttaki alanın boyutuna eşittir.
Altta yatan alan olarak GF(2^16) kullanmanızı öneriyoruz. Altta yatan KEM olarak ML-KEM 768 [1] ve 32 baytlık kod sözcükleri kullanıldığında, protokolün gönderdiği en büyük ileti 36 kod sözcüğü uzunluğundadır. Dolayısıyla cırcırlamayı engellemek için saldırganın her 2^16 iletiden 2^16 - 35 tanesinin teslimini engellemesi gerekir. Bu tam bir hizmet reddi olmasa da iletilerin %99,9'undan fazlasını engellemeyi gerektirir ve büyük olasılıkla protokol kullanıcılarının alttaki hizmeti kullanılamaz kabul etmesine yol açar.
GF(2^8) kullanılması daha hızlı kodlama ve çözümleme sağlar; ancak bu kez bir saldırganın 256 iletiden 221'ini, yani iletilerin %86'sını engelleyerek protokolün ilerlemesini önlemesine imkân tanır. Bu büyük olasılıkla zayıf bir kullanıcı deneyimine yol açar; ancak yine de daha üst düzey bir protokolü kullanılabilir bırakabilir. Eğer bir uygulama için kodlama ve çözümleme hızı kritikse, sonraki bölümde açıklandığı gibi fountain code kullanımını değerlendirmenizi öneririz.
3.6 Alternatif kodlayıcılar
Büyük iletileri sabit boyutlu parçalara ayırmak için sistematik bir silme kodu temelli kodlama düzeni kullanmanızı öneriyoruz. Sistematik kodlamalar, hiçbir iletinin düşmediği yaygın durumda çözümlemenin yalnızca birleştirme olması nedeniyle çok verimlidir. Silme kodları bize, bir iletinin düz metni N kod sözcüğüne sığıyorsa, alıcı bu kod sözcüklerinden herhangi N tanesini aldığında iletinin çözümünü yapabileceği garantisini verir.
Silme kodu çözümlemesinin hesaplama maliyetleri çok yüksekse, RaptorQ [11] gibi bir fountain code kullanılabilir. Fountain code ile alıcı, bir iletinin düz metni N kod sözcüğüne sığıyorsa, alıcının herhangi N kod sözcüğü aldığında iletinin çözümünü yapabileceğine dair garantiyi kaybeder. Bununla birlikte çoğu durumda alıcı yine de N kod sözcüğünden iletinin çözümünü yapabilecektir. Örneğin RaptorQ için çözücülerin N kod sözcüğünden çözümlemede en az 100 denemenin 99'unda başarılı olması ve N+k kod sözcüğünden çözümlemeyi en az 1 - 10^(-k-1) olasılıkla başarması gerekir.
Her epoch'ta dört ileti çözülmek zorunda olduğundan, RaptorQ kullanan bir uygulamanın, silme kodu tabanlı bir uygulamaya göre bir epoch içinde yaklaşık %4 oranında daha fazla ileti göndermek zorunda kalmasını bekleyebiliriz.
Bu, daha üst düzey herhangi bir protokolün güvenliği üzerinde olumsuz etki yapabilir. Örneğin bunu kullanan bir Double Ratchet protokolünde [2], bu doğrudan Vulnerable Message Set'in, yani cihazın ele geçirilmesi durumunda saldırgana açık kalan ileti kümesinin, yaklaşık %4 oranında büyümesine yol açar. (Vulnerable Message Set hakkında daha fazla ayrıntı için [3]'e bakın.)
3.7 Biçimsel doğrulama ve güvenlik kanıtları
ML-KEM Braid protokolü ProVerif [12] kullanılarak modellenmiş ve [3]'te tanımlanan bir SCKA protokolü için gerekli doğruluk, Forward Secrecy ve Post-Compromise Security özelliklerini Dolev-Yao modelinde sağladığı kanıtlanmıştır. Ayrıca bu modeller ML-KEM Braid protokolü için karşılıklı doğrulamayı da kanıtlamaktadır.
ML-KEM Braid protokolü, [3]'te tanıtılan ve güvenli bir SCKA olduğu kanıtlanan Opp-UniKEM-CKA protokolüyle yakından ilişkilidir.
Uygulama ve ProVerif modelleri [13]'te mevcuttur.
3.8 Epoch'ların gösterimi
Bir uygulama epoch'u temsil etmek için sabit genişlikte bir tamsayı kullanırsa, sonunda epoch sayacı tekrar etmeye başlar ve protokol her epoch'un benzersiz anahtar ürettiği özelliğini kaybeder. Örneğin protokol iletilerinde yer kazanmak için epoch'lar için 8 bitlik tamsayı kullanan bir uygulama, 256 anahtar üretildikten sonra epoch'ları tekrar etmeye başlar; bu da birçok konuşmada gerçekleşmesi muhtemel bir durumdur. Epoch'u temsil etmek için 64 bitlik bir tamsayı kullanmak, insan konuşmasında bu taşmanın yaşanmasını pratikte engeller; ancak ML-KEM Braid'in başka uygulamalarında bu taşma dikkate alınmalıdır.