Not
Öneri aşaması kapatılmıştır.
Resmi spesifikasyon için SPEC
adresine bakın.
Bu öneri, arka plan bilgisi için hâlâ referans alınabilir.
Genel Bakış
Bu öneri, NTCP üzerinde çeşitli otomatik tanımlama ve saldırı türlerine karşı direnci artırmak için bir kimlik doğrulamalı anahtar anlaşma protokolünü tanımlar.
Öneri şu şekilde düzenlenmiştir: güvenlik hedefleri sunulur, ardından temel protokol tartışılır. Daha sonra tüm protokol mesajlarının tam bir spesifikasyonu verilir. Son olarak, yönlendirici adresleri ve sürüm tanımlaması ele alınır. Yaygın dolgu şemalarına yönelik genel bir saldırı üzerine bir ek ve ayrıca kimlik doğrulamalı şifreleme için bir dizi aday içeren bir ek daha eklenmiştir.
Diğer I2P aktarımlarında olduğu gibi, NTCP2 yalnızca I2NP mesajlarının noktadan-noktaya (yönlendirici-yönlendirici) aktarımı için tanımlanmıştır.
Genel amaçlı bir veri hattı değildir.
Motivasyon
NTCP verisi ilk mesajdan sonra şifrelenir (ve ilk mesaj rastgele veri gibi görünür), bu da “yük analizi” ile protokol tanımlamasını önler. Hâlâ “akış analizi” ile protokol tanımlamasına karşı savunmasızdır. Bunun nedeni ilk 4 mesajın (yani el sıkışma aşamasının) sabit uzunlukta olmasıdır (288, 304, 448 ve 48 bayt).
Her mesaja rastgele miktarda rastgele veri ekleyerek bunu çok daha zor hale getirebiliriz.
Yazarlar, standart güvenlik uygulamalarının mevcut bir protokol olan TLS gibi bir şey kullanılmasını önerdiğini kabul eder, ancak bu Prop104 konusudur ve kendi sorunlarına sahiptir. Uygun yerlerde, eksik özellikler veya tartışma konularını belirtmek için “gelecek iş” paragrafları eklenmiştir.
Tasarım Hedefleri
Tek bir portta NTCP 1 ve 2’yi destekleyin, otomatik olarak tespit edin ve bunları NetDB içinde tek bir “aktarım” (yani RouterAddress) olarak yayınlayın.
NetDB’de yalnızca sürüm 1, yalnızca sürüm 2 veya 1+2 desteği yayınlayın ve varsayılan olarak yalnızca sürüm 1’e ayarlayın (sürüm desteğini belirli bir yönlendirici sürümüne bağlamanın).
Tüm uygulamaların (Java/i2pd/Kovri/go) kendi zamanlamalarında sürüm 2 desteğini (veya desteklememeyi) ekleyebilmesini sağlayın.
El sıkışma ve veri mesajları dahil olmak üzere tüm NTCP mesajlarına rastgele dolgu ekleyin (yani uzunluk gizleme, böylece tüm mesajlar 16 baytın katı olmasın). Her iki tarafın da minimum ve maksimum dolgu veya dolgu dağılımını talep edebilmesi için bir seçenekler mekanizması sağlayın. Dolgu dağılımının belirli özellikleri uygulamaya bağlıdır ve protokolün kendisinde belirtilmiş olmayabilir.
Şifrelenmemiş mesajların içeriğini (1 ve 2) gizleyin, böylece DPI kutuları ve AV imzaları bunları kolayca sınıflandıramasın. Ayrıca, tek bir eş veya eşler kümesine giden mesajların benzer bir bit desenine sahip olmamasını sağlayın.
Java formatından kaynaklanan DH’deki bit kaybını düzeltin Ticket1112 , muhtemelen (muhtemelen?) X25519’e geçerek.
DH sonucunu olduğu gibi kullanmak yerine, gerçek bir anahtar türetme işlevi (KDF) kullanın mı?
“Probing direnci” (Tor’un adlandırdığı gibi); bu, tekrar oynatma direncini de içerir.
İki yönlü kimlik doğrulamalı anahtar değişimi (2W-AKE) koruyun. 1W-AKE uygulamamız için yeterli değildir.
Kimlik doğrulamanın bir parçası olarak, yayınlanan RouterIdentity imza anahtarıyla imzalanan değişken türde, değişken uzunluklu imzaları kullanmaya devam edin. Kimlik doğrulamanın başka bir parçası olarak, RouterInfo’da yayınlanan statik ortak anahtara güvenin.
Gelecekteki genişletilebilirlik için el sıkışmaya seçenekler/sürüm ekleyin.
Mümkünse kötü niyetli MitM TCP segmentasyonuna karşı direnç ekleyin.
Bağlantı kurulumu için gereken CPU’yu önemli ölçüde artırmayın; mümkünse, onu önemli ölçüde azaltın.
Mesaj kimlik doğrulaması (MAC) ekleyin, muhtemelen HMAC-SHA256 ve Poly1305, ve Adler checksum’ı kaldırın.
I2NP başlığını kısaltın ve basitleştirin:
SSU’daki gibi süreyi 4 bayta kısaltın.
Bir baytlık kesilmiş SHA256 checksum’ı kaldırın.Mümkünse, 4 mesajlı, iki turculuk el sıkışmayı, SSU gibi 3 mesajlı, tek turculuk el sıkışmaya indirin. Bu, Bob’un imzasını mesaj 4’ten mesaj 2’ye taşımayı gerektirir. On yıllık e-posta/durum/toplantı arşivlerinde 4 mesajın nedenini araştırın.
Dolgudan önce protokol ek yükünü en aza indirin. Dolgu eklenecek ve muhtemelen çok fazla olacak olsa da, dolgudan önceki ek yük hâlâ ek yüktür. Düşük bant genişlikli düğümler NTCP2’yi kullanabilmelidir.
Tekrar oynatma ve sapma tespiti için zaman damgalarını koruyun.
Zaman damgalarında 2038 yılı sorunlarından kaçının, en az 2106’ya kadar çalışmalıdır.
Maksimum mesaj boyutunu 16K’dan 32K veya 64K’ya çıkarın.
Yeni kriptografik ilkelar, Java (1.7), C++ ve Go yönlendirici uygulamalarında kullanılacak kütüphanelerde kolayca mevcut olmalıdır.
Java, C++ ve Go yönlendirici geliştiricilerinin temsilcilerini tasarıma dahil edin.
Değişiklikleri en aza indirin (ancak yine de çok olacaktır).
Her iki sürümü de ortak bir kod setinde destekleyin (bu mümkün olmayabilir ve her durumda uygulamaya bağlıdır).
Hedef Olmayanlar
Mermi geçirmez DPI direnci… bu pluggable aktarımlar olurdu, Prop109 .
TLS tabanlı (veya HTTPS benzeri) bir aktarım… bu Prop104 olurdu.
Simetrik akış şifrelemesini değiştirmek sorun değil.
Zamanlama tabanlı DPI direnci (mesajlar arası zamanlama/gecikmeler uygulamaya bağlı olabilir; mesaj içi gecikmeler, örneğin rastgele dolguyu göndermeden önce herhangi bir noktada eklenebilir). Yapay gecikmeler (obfs4’ün IAT veya araya varış süresi dediği) protokolün kendisinden bağımsızdır.
Bir oturumda katılımdan dolayı inkâr edilebilirlik (içinde imzalar var).
Kısmen yeniden değerlendirilebilecek veya tartışılacak olmayan hedefler:
Derin Paket İncelemesi’ne (DPI) karşı koruma derecesi
Kuantum Sonrası (PQ) güvenlik
İnkâr edilebilirlik
İlgili Hedefler
- Bir NTCP 1/2 test kurulumu uygulayın
Güvenlik Hedefleri
Üç tarafı dikkate alıyoruz:
- Alice, yeni bir oturum kurmak istiyor.
- Bob, Alice’in oturum kurmak istediği kişi.
- Mallory, Alice ve Bob arasındaki “araya giren adam”.
En fazla iki katılımcı aktif saldırılar gerçekleştirebilir.
Alice ve Bob, RouterIdentity’lerinde bulunan statik anahtar çiftine sahiptir.
Önerilen protokol, Alice ve Bob’un aşağıdaki gereksinimlere göre gizli bir oturum anahtarı (K) üzerinde anlaşmalarını sağlamayı dener:
Özel anahtar güvenliği: Bob veya Mallory, Alice’in statik özel anahtarı hakkında hiçbir şey öğrenemez. Simetrik olarak, Alice Bob’un statik özel anahtarı hakkında hiçbir şey öğrenemez.
Oturum anahtarı K yalnızca Alice ve Bob tarafından bilinir.
Mükemmel ileri gizlilik: Anlaşmaya varılan oturum anahtarı, Alice ve/veya Bob’un statik özel anahtarları daha sonra ortaya çıkarılsa bile gelecekte gizli kalır.
İki yönlü kimlik doğrulama: Alice, Bob ile bir oturum kurduğundan emindir ve tam tersi de geçerlidir.
Çevrimiçi DPI’ye karşı koruma: Alice ve Bob’un yalnızca basit derin paket incelemesi (DPI) tekniklerini kullanarak protokolde bulunduğunu tespit etmenin önemsiz olmadığından emin olun. Aşağıya bakın.
Sınırlı inkâr edilebilirlik: Alice veya Bob, protokolde katılımdan dolayı inkâr edemez, ancak biri paylaşılan anahtarı sızdırırsa diğer taraf, iletilen verilerin içeriğinin kimliğini inkâr edebilir.
Mevcut öneri, Station-To-Station (STS) protokolüne dayanarak tüm beş gereksinimi sağlamayı dener. Bu protokolün aynı zamanda SSU protokolünün temeli olduğu dikkate alınmalıdır.
Ek DPI Tartışması
İki DPI bileşenimiz olduğunu varsayıyoruz:
1) Çevrimiçi DPI
Çevrimiçi DPI, tüm akışları gerçek zamanlı olarak inceler. Bağlantılar engellenebilir veya başka şekilde değiştirilebilir. Bağlantı verileri veya meta verileri tanımlanabilir ve çevrimdışı analiz için saklanabilir. Çevrimiçi DPI’nin I2P ağ veritabanına erişimi yoktur. Çevrimiçi DPI’nin sınırlı gerçek zamanlı hesaplama kapasitesi vardır, uzunluk hesaplama, alan incelemesi ve XOR gibi basit hesaplamaları içerir. Çevrimiçi DPI, AES, AEAD ve hashing gibi hızlı gerçek zamanlı kriptografik fonksiyonları uygulama kapasitesine sahiptir, ancak bunlar çoğu veya tüm akışlara uygulanması çok maliyetli olur. Bu kriptografik işlemlerin uygulanması yalnızca çevrimdışı analizle daha önce tanımlanmış IP/Port kombinasyonlarındaki akışlara uygulanır. Çevrimiçi DPI, DH veya elligator2 gibi yüksek maliyetli kriptografik fonksiyonları kullanma kapasitesine sahip değildir. Çevrimiçi DPI, özellikle I2P’yi tespit etmek için tasarlanmamıştır, ancak bu amaçla sınırlı sınıflandırma kurallarına sahip olabilir.
Çevrimiçi DPI tarafından protokol tanımlamasını önlemek bir hedeftir.
Çevrimiçi veya “basit” DPI’nin burada alınan kavramı, aşağıdaki saldırgan yetenekleri içerir:
Hedef tarafından gönderilen veya alınan tüm verileri inceleme yeteneği.
Gözlemlenen verilere blok şifreler veya hash fonksiyonları uygulama gibi işlemler yapma yeteneği.
Daha önce gönderilen mesajlarla karşılaştırmak için saklama yeteneği.
Paketleri değiştirme, geciktirme veya parçalama yeteneği.
Ancak, çevrimiçi DPI’nin aşağıdaki kısıtlamalara sahip olduğu varsayılır:
IP adreslerini yönlendirici hash’lerine eşleme yeteneği yoktur. Bu, ağ veritabanına gerçek zamanlı erişimle basit olsa da, I2P’yi hedef almak için özel olarak tasarlanmış bir DPI sistemini gerektirir.
Protokolü tespit etmek için zamanlama bilgisini kullanma yeteneği yoktur.
Genel olarak, çevrimiçi DPI araç kutusunda I2P tespiti için özel olarak tasarlanmış herhangi bir araç bulunmaz. Bu, mesajlarında rastgele olmayan dolgu içeren “tuzak” sistemler oluşturmayı da içerir. Bunun, diğer gereksinimleri karşıladığı sürece makine öğrenimi sistemleri veya yüksek düzeyde yapılandırılabilir DPI araçlarını dışlamadığını unutmayın.
Yük analizine karşı korunmak için, tüm mesajların rastgele veriden ayırt edilemez olması sağlanır. Bu aynı zamanda uzunluklarının rastgele olması gerektiği anlamına gelir, bu sadece rastgele dolgu eklemekten daha karmaşıktır. Aslında, Ek A’da yazarlar, basit (yani uniform) bir dolgu şemasının sorunu çözmediğini savunur. Bu nedenle Ek A, ya rastgele gecikmeler eklemeyi ya da önerilen saldırıya makul koruma sağlayabilecek alternatif bir dolgu şeması geliştirmeyi önerir.
Yukarıdaki altıncı maddeye karşı korunmak için, uygulamalar protokole rastgele gecikmeler eklemelidir. Bu tür teknikler bu öneri kapsamında değildir, ancak dolgu uzunluğu sorunlarını da çözebilir. Özetle, öneri (Ek A’daki hususlar dikkate alındığında) yük analizine karşı iyi koruma sağlar, ancak akış analizine karşı yalnızca sınırlı koruma sağlar.
2) Çevrimdışı DPI
Çevrimdışı DPI, çevrimiçi DPI tarafından daha sonra analiz için saklanan verileri inceler. Çevrimdışı DPI, özellikle I2P’yi tespit etmek için tasarlanmış olabilir. Çevrimdışı DPI’nin I2P ağ veritabanına gerçek zamanlı erişimi vardır. Çevrimdışı DPI, bu ve diğer I2P spesifikasyonlarına erişim hakkına sahiptir. Çevrimdışı DPI, bu spesifikasyonda tanımlanan tüm kriptografik fonksiyonları içeren sınırsız hesaplama kapasitesine sahiptir.
Çevrimdışı DPI’nin mevcut bağlantıları engelleme yeteneği yoktur. Çevrimdışı DPI, kurulumdan dakikalar içinde (modifiye edilmiş veya edilmemiş) önceki mesajları “probing” veya diğer nedenlerle tekrar oynatma yeteneğine sahiptir. Çevrimdışı DPI’nin hedefe/porte gönderim yapma yeteneği vardır.
Çevrimdışı DPI tarafından protokol tanımlamasını önlemek bir hedef değildir. İlk iki mesajdaki şifrelenmiş verilerin I2P yönlendiricileri tarafından uygulanan tüm çözümleri, çevrimdışı DPI tarafından da uygulanabilir.
Daha önceki mesajların tekrar oynatılmasıyla yapılan bağlantı girişimlerini reddetmek bir hedeftir.
Gelecek iş
Paketlerin bir saldırgan tarafından bırakılması veya yeniden sıralanması durumunda protokolün davranışını düşünün. Bu alandaki son ilginç çalışmalar IACR-1150 adresinde bulunabilir.
Konuyla ilgili mevcut literatürü dikkate alarak DPI sistemlerinin daha doğru bir sınıflandırmasını sağlayın.
Önerilen protokolün resmi güvenliğini, ideal olarak DPI saldırgan modelini dikkate alarak tartışın.
Gürültü Protokol Çerçevesi
Bu öneri, Gürültü Protokol Çerçevesi’ne NOISE (Revizyon 33, 2017-10-04) dayalı gereksinimleri sağlar. Gürültü, SSU protokolünün temeli olan Station-To-Station protokolüne benzer özelliklere sahiptir. Gürültü terminolojisinde, Alice başlatıcıdır ve Bob yanıt vericidir.
NTCP2, Noise_XK_25519_ChaChaPoly_SHA256 protokolüne dayanır.
(Gerçek kimlik doğrulama fonksiyonu için ilk anahtar türetme fonksiyonunun gerçek tanımlayıcısı, I2P uzantılarını belirtmek için “Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256"dır - aşağıya KDF 1 bölümüne bakın)
Bu Gürültü protokolü aşağıdaki ilkeları kullanır:
El sıkışma Deseni: XK
Alice, anahtarını Bob’a iletir (X)
Alice, Bob’un statik anahtarını zaten bilir (K)DH Fonksiyonu: X25519
RFC-7748 belgesinde belirtildiği gibi 32 bayt uzunluğunda X25519 DH.Şifreleme Fonksiyonu: ChaChaPoly
RFC-7539 bölüm 2.8’de belirtildiği gibi AEAD_CHACHA20_POLY1305.
12 baytlık nonce, ilk 4 baytı sıfıra ayarlanmıştır.Hash Fonksiyonu: SHA256
Standart 32 baytlık hash, I2P’de zaten yaygın olarak kullanılmaktadır.
Çerçeveye Eklemeler
Bu öneri, Noise_XK_25519_ChaChaPoly_SHA256’e aşağıdaki geliştirmeleri tanımlar. Bunlar genellikle NOISE bölüm 13’teki kuralları takip eder.
Açık metin geçici anahtarları, bilinen bir anahtar ve IV kullanılarak AES şifrelemesiyle gizlenir. Bu, elligator2’den daha hızlıdır.
Mesajlara 1 ve 2’ye rastgele açık metin dolgusu eklenir.
Açık metin dolgusu, el sıkışma hash (MixHash) hesaplamasına dahil edilir.
Mesaj 2 ve mesaj 3 bölüm 1 için KDF bölümlerine bakın.
Mesaj 3 ve veri aşaması mesajlarına rastgele AEAD dolgusu eklenir.Gürültü’nün TCP üzerinde olması gerektiği gibi ve obfs4’te olduğu gibi, iki baytlık çerçeve uzunluğu alanı eklenir. Bu yalnızca veri aşaması mesajlarında kullanılır.
Mesaj 1 ve 2 AEAD çerçeveleri sabit uzunluktadır.
Mesaj 3 bölüm 1 AEAD çerçevesi sabit uzunluktadır.
Mesaj 3 bölüm 2 AEAD çerçevesi uzunluğu mesaj 1’de belirtilir.İki baytlık çerçeve uzunluğu alanı, obfs4’te olduğu gibi SipHash-2-4 ile gizlenir.
Mesajların 1,2,3 ve veri aşaması için yük formatı tanımlanır. Elbette, bu Gürültü’de tanımlanmaz.
I2P için Yeni Kriptografik İlkelar
Mevcut I2P yönlendirici uygulamaları, şu anda I2P protokollerinde gerekli olmayan aşağıdaki standart kriptografik ilkelar için uygulamalara ihtiyaç duyar:
X25519 anahtar üretimi ve DH
AEAD_ChaCha20_Poly1305 (aşağıda ChaChaPoly olarak kısaltılmıştır)
SipHash-2-4
İşlem ek yükü tahmini
3 mesaj için mesaj boyutları:
- 64 bayt + dolgu (NTCP 288 bayttı)
- 64 bayt + dolgu (NTCP 304 bayttı)
- yaklaşık 64 bayt + Alice yönlendirici bilgisi + dolgu Ortalama yönlendirici bilgisi yaklaşık 750 bayttır
Dolgudan önceki toplam ortalama 814 bayt (NTCP 448 bayttı) - NTCP2’de gerekli değil (NTCP 48 bayttı)
Dolgudan önceki toplam:
NTCP2: 942 bayt
NTCP: 1088 bayt
Alice’in Bob’a RouterInfo’sini içeren bir DatabaseStore Mesajı göndermek amacıyla bağlandığını varsayarsak, bu mesaj gerekli değildir ve yaklaşık 800 bayt tasarruf edilir.
El sıkışmayı tamamlamak ve veri aşamasını başlatmak için her tarafın gerekli kriptografik işlemleri:
- AES: 2
- SHA256: 7 (Alice), 6 (Bob) (tüm bağlantılar için önceden hesaplanan 1 Alice, 2 Bob dahil değil) (HMAC-SHA256 dahil değil)
- HMAC-SHA256: 19
- ChaChaPoly: 4
- X25519 anahtar üretimi: 1
- X25519 DH: 3
- İmza doğrulaması: 1 (Bob) (Alice, RI’sini oluştururken daha önce imzalamıştır) Muhtemelen Ed25519 (RI imza türüne bağlı)
Her veri aşaması mesajı için her tarafın gerekli kriptografik işlemleri:
- SipHash: 1
- ChaChaPoly: 1
Mesajlar
Tüm NTCP2 mesajları uzunluk olarak 65537 bayttan küçük veya eşittir. Mesaj formatı, çerçeveleme ve ayırt edilemezlik için modifikasyonlarla Noise mesajlarına dayanır. Standart Noise kütüphaneleri kullanan uygulamalar, Noise mesaj formatına gelen/giden mesajları önceden işlemek zorunda kalabilir. Şifrelenmiş alanlar AEAD şifre metinleridir.
Kurulum sırası şu şekildedir:
Alice Bob
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->
Gürültü terminolojisini kullanarak, kurulum ve veri sırası şu şekildedir: (Yük Güvenlik Özellikleri)
XK(s, rs): Kimlik Doğrulama Gizlilik
<- s
...
-> e, es 0 2
<- e, ee 2 1
-> s, se 2 5
<- 2 5
Bir oturum kurulduktan sonra, Alice ve Bob veri mesajlarını değiştirebilir.
Tüm mesaj türleri (SessionRequest, SessionCreated, SessionConfirmed, Data ve TimeSync) bu bölümde belirtilmiştir.
Bazı gösterimler:
- RH_A = Alice için Yönlendirici Hash (32 bayt)
- RH_B = Bob için Yönlendirici Hash (32 bayt)
Kimlik Doğrulamalı Şifreleme
Üç ayrı kimlik doğrulamalı şifreleme örneği (CipherStates) vardır. El sıkışma aşamasında bir tane ve veri aşaması için iki tane (gönderim ve alma). Her biri KDF’den gelen kendi anahtarına sahiptir.
Şifrelenmiş/kimlik doğrulanan veriler şu şekilde temsil edilir:
+----+----+----+----+----+----+----+----+
| |
+ +
| Şifrelenmiş ve kimlik doğrulanan veri |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
ChaCha20/Poly1305
Şifrelenmiş ve kimlik doğrulanan veri formatı.
Şifreleme/çözme fonksiyonlarına girdiler:
k :: 32 baytlık şifre anahtarı, KDF'den üretildiği gibi
nonce :: Sayı tabanlı nonce, 12 bayt.
0'dan başlar ve her mesajda artırılır.
İlk dört bayt her zaman sıfırdır.
Son sekiz bayt sayaçtır, little-endian kodlanmıştır.
Maksimum değer 2**64 - 2'dir.
Bu değere ulaşıldığında bağlantı düşürülmeli ve yeniden başlatılmalıdır.
2**64 - 1 değeri asla gönderilmemelidir.
ad :: El sıkışma aşamasında:
İlişkili veri, 32 bayt.
Önceki tüm verilerin SHA256 hash'i.
Veri aşamasında:
Sıfır baytlar
data :: Düz metin verisi, 0 veya daha fazla bayt
Şifreleme fonksiyonunun çıktısı, çözme fonksiyonunun girdisi:
+----+----+----+----+----+----+----+----+
|Obfs Uzunluk | |
+----+----+ +
| ChaCha20 şifrelenmiş veri |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Mesaj Kimlik Doğrulama Kodu |
+ (MAC) +
| 16 bayt |
+----+----+----+----+----+----+----+----+
Obfs Uzunluk :: Takip edecek (şifrelenmiş veri + MAC) uzunluğu, 16 - 65535
SipHash kullanılarak gizleme (aşağıya bakın)
Mesaj 1 veya 2'de ve mesaj 3 bölüm 1'de kullanılmaz, burada uzunluk sabittir
Mesaj 3 bölüm 1'de kullanılmaz, çünkü uzunluk mesaj 1'de belirtilmiştir
şifrelenmiş veri :: Düz metin verisiyle aynı boyutta, 0 - 65519 bayt
MAC :: Poly1305 mesaj kimlik doğrulama kodu, 16 bayt
ChaCha20 için burada açıklanan, RFC-7539 belgesine karşılık gelir, bu aynı zamanda TLS’de RFC-7905 benzer şekilde kullanılır.
Notlar
ChaCha20 bir akış şifresi olduğundan, düz metinlerin dolguya ihtiyacı yoktur.
Ek anahtar akışı baytları atılır.Şifre anahtarı (256 bit) SHA256 KDF ile anlaşılır.
Her mesaj için KDF’nin ayrıntıları aşağıda ayrı bölümlerde verilmiştir.Mesaj 1, 2 ve mesaj 3’ün ilk kısmı için ChaChaPoly çerçeveleri bilinen boyuttadır. Mesaj 3’ün ikinci kısmından itibaren çerçeveler değişken boyuttadır. Mesaj 3 bölüm 1 boyutu mesaj 1’de belirtilir. Veri aşamasından itibaren çerçeveler, obfs4’te olduğu gibi SipHash ile gizlenmiş iki baytlık uzunlukla başlar.
Mesaj 1 ve 2 için dolgu, kimlik doğrulanan veri çerçevesinin dışındadır.
Dolgu, bir sonraki mesaj için KDF’de kullanılacağından, değiştirilmesi tespit edilir.
Mesaj 3’ten itibaren dolgu, kimlik doğrulanan veri çerçevesinin içindedir.
AEAD Hata İşleme
Mesaj 1, 2 ve mesaj 3 bölümler 1 ve 2’de, AEAD mesaj boyutu önceden bilinir.
AEAD kimlik doğrulama hatası durumunda, alıcı daha fazla mesaj işleme yapmayı durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu, abnormal bir kapanış (TCP RST) olmalıdır.Probing direnci için, mesaj 1’de AEAD hatası sonrası, Bob rastgele bir zaman aşımı (aralık TBD) ayarlamalı ve ardından soketi kapatmadan önce rastgele bayt sayısı (aralık TBD) okumalıdır. Bob, tekrarlanan hatalarla birlikte IP’leri bir kara listeye almalıdır.
Veri aşamasında, AEAD mesaj boyutu SipHash ile “şifrelenir” (gizlenir).
Bir şifre çözme oracle’ı yaratmaktan kaçınmak için dikkatli olunmalıdır.
Veri aşaması AEAD kimlik doğrulama hatası durumunda, alıcı rastgele bir zaman aşımı (aralık TBD) ayarlamalı ve ardından rastgele bayt sayısı (aralık TBD) okumalıdır.
Okuma sonrası veya okuma zaman aşımında, alıcı bir “AEAD hatası” neden kodu içeren sonlandırma bloğu içeren bir yük göndermeli ve bağlantıyı kapatmalıdır.Veri aşamasında geçersiz uzunluk alanı değeri için aynı hata eylemini alın.
Anahtar Türetme Fonksiyonu (KDF) (el sıkışma mesajı 1 için)
KDF, DH sonucundan el sıkışma aşaması şifre anahtarı k üretir, RFC-2104 belgesinde tanımlandığı gibi HMAC-SHA256(anahtar, veri) kullanır. Bunlar, Gürültü spesifikasyonunda tam olarak tanımlandığı gibi InitializeSymmetric(), MixHash() ve MixKey() fonksiyonlarıdır.
Bu "e" mesaj desenidir:
// protocol_name tanımla.
protocol_name = "Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256" olarak ayarla
(48 bayt, US-ASCII kodlu, NULL sonlandırma yok).
// Hash h = 32 bayt tanımla
h = SHA256(protocol_name);
32 baytlık zincirleme anahtarı ck tanımla. h verilerini ck'ye kopyala.
ck = h olarak ayarla
RouterInfo'da yayınlanan Bob'un 32 baytlık statik anahtarı rs olarak tanımla
// MixHash(null prologue)
h = SHA256(h);
// buraya kadar, Alice tarafından tüm giden bağlantılar için önceden hesaplanabilir
// Alice, Bob'un statik anahtarının eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.
// Bob statik anahtarı
// MixHash(rs)
// || aşağıda ekleme anlamına gelir
h = SHA256(h || rs);
// buraya kadar, Bob tarafından tüm gelen bağlantılar için önceden hesaplanabilir
Bu "e" mesaj desenidir:
Alice, geçici DH anahtar çifti e üretir.
// Alice geçici anahtarı X
// MixHash(e.pubkey)
// || aşağıda ekleme anlamına gelir
h = SHA256(h || e.pubkey);
// h, mesaj 1'deki AEAD için ilişkili veri olarak kullanılır
// Mesaj 2 KDF'si için Hash h'yi sakla
"e" mesaj deseninin sonu.
Bu "es" mesaj desenidir:
// DH(e, rs) == DH(s, re)
Alice'in geçici anahtarı ve Bob'un statik anahtarı arasındaki DH sonucunun 32 baytlık input_key_material tanımla
input_key_material = X25519 DH sonucu olarak ayarla
// MixKey(DH())
32 baytlık temp_key tanımla
[RFC-2104](https://tools.ietf.org/html/rfc2104) belgesinde tanımlandığı gibi HMAC-SHA256(anahtar, veri) tanımla
// Zincirleme anahtarı ve DH sonucundan geçici bir anahtar üret
// ck yukarıda tanımlanan zincirleme anahtarıdır
temp_key = HMAC-SHA256(ck, input_key_material)
// bellekteki DH sonucunu sıfırla, artık gerekli değil
input_key_material = (tüm sıfırlar)
// Çıktı 1
// Yeni bir zincirleme anahtarı temp_key'den üret
// byte() aşağıda tek bir bayt anlamına gelir
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Çıktı 2
// Şifre anahtarı k üret
32 baytlık k tanımla
// || aşağıda ekleme anlamına gelir
// byte() aşağıda tek bir bayt anlamına gelir
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// bellekteki temp_key'i sıfırla, artık gerekli değil
temp_key = (tüm sıfırlar)
// mesaj 2 KDF'si için zincirleme anahtarı ck'yi sakla
"es" mesaj deseninin sonu.
1) SessionRequest
Alice, Bob’a gönderir.
Gürültü içeriği: Alice’in geçici anahtarı X
Gürültü yükü: 16 baytlık seçenek bloğu
Gürültü dışı yük: Rastgele dolgu
(Yük Güvenlik Özellikleri)
XK(s, rs): Kimlik Doğrulama Gizlilik
-> e, es 0 2
Kimlik Doğrulama: Yok (0).
Bu yük, herhangi bir taraf, dahil olmak üzere aktif bir saldırgan tarafından gönderilmiş olabilir.
Gizlilik: 2.
Bilinen bir alıcıya şifreleme, yalnızca gönderenin tehlikeye girmesi durumunda ileri gizlilik, tekrar oynatmaya karşı savunmasız. Bu yük, yalnızca alıcının statik anahtar çiftiyle ilgili DH'ler temel alınarak şifrelenir. Alıcının statik özel anahtarı tehlikeye girerse, hatta daha sonra bile, bu yük çözülebilir. Bu mesaj ayrıca tekrar oynatılabilir, çünkü alıcıdan geçici bir katkı yoktur.
"e": Alice yeni bir geçici anahtar çifti üretir ve e değişkeninde saklar, geçici ortak anahtarı açık metin olarak mesaj arabelleğine yazar ve eski h ile birlikte ortak anahtarı hashleyerek yeni bir h türetir.
"es": Alice'in geçici anahtar çifti ile Bob'un statik anahtar çifti arasında bir DH gerçekleştirilir. Sonuç, eski ck ile birlikte hashlenerek yeni bir ck ve k türetilir ve n sıfıra ayarlanır.
X değeri, yükün ayırt edilemezliğini ve benzersizliğini sağlamak için şifrelenir, bu gerekli DPI karşı önlemlerdir.
Bu amaçla AES şifrelemesi kullanıyoruz, elligator2 gibi daha karmaşık ve yavaş alternatifler yerine.
Bob’un yönlendirici ortak anahtarına asimetrik şifreleme çok yavaştır.
AES şifreleme, Bob’un yönlendirici hash’ini anahtar olarak ve Bob’un IV’sini ağ veritabanında yayınlandığı gibi kullanır.
AES şifreleme yalnızca DPI direnci içindir.
Bob’un yönlendirici hash’ini ve IV’sini bilen herhangi bir taraf, ağ veritabanında yayınlandığı için bu mesajdaki X değerini çözebilir.
Dolgu, Alice tarafından şifrelenmez.
Bob’un dolguyu çözmek zorunda olabileceği, zamanlama saldırılarını engellemek için.
Ham içerikler:
+----+----+----+----+----+----+----+----+
| |
+ RH_B ile gizlenmiş +
| AES-CBC-256 şifrelenmiş X |
+ (32 bayt) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| ChaChaPoly çerçeve |
+ (32 bayt) +
| k mesaj 1 KDF'siyle tanımlanır |
+ n = 0 +
| ilişkili veri için KDF'ye bakın |
+----+----+----+----+----+----+----+----+
| şifrelenmemiş kimlik doğrulanan |
~ dolgu (isteğe bağlı) ~
| uzunluk seçenekler bloğunda tanımlanır |
+----+----+----+----+----+----+----+----+
X :: 32 bayt, AES-256-CBC şifrelenmiş X25519 geçici anahtarı, little endian
anahtar: RH_B
iv: Bob'un ağ veritabanı girdisinde yayınlandığı gibi
dolgu :: Rastgele veri, 0 veya daha fazla bayt.
Toplam mesaj uzunluğu 65535 bayt veya daha az olmalıdır.
Toplam mesaj uzunluğu 287 bayt veya daha az olmalıdır, eğer
Bob adresini NTCP olarak yayınlıyorsa
(aşağıdaki Sürüm Tespiti bölümüne bakın).
Alice ve Bob, mesaj 2 KDF'si için dolgu verisini kullanacaktır.
Herhangi bir değiştirilme, bir sonraki mesajın başarısız olmasına neden olacak şekilde kimlik doğrulanır.
Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmez):
+----+----+----+----+----+----+----+----+
| |
+ +
| X |
+ (32 bayt) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| seçenekler |
+ (16 bayt) +
| |
+----+----+----+----+----+----+----+----+
| şifrelenmemiş kimlik doğrulanan |
+ dolgu (isteğe bağlı) +
| uzunluk seçenekler bloğunda tanımlanır |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
X :: 32 bayt, X25519 geçici anahtarı, little endian
seçenekler :: seçenekler bloğu, 16 bayt, aşağıya bakın
dolgu :: Rastgele veri, 0 veya daha fazla bayt.
Toplam mesaj uzunluğu 65535 bayt veya daha az olmalıdır.
Toplam mesaj uzunluğu 287 bayt veya daha az olmalıdır, eğer
Bob adresini "NTCP" olarak yayınlıyorsa
(aşağıdaki Sürüm Tespiti bölümüne bakın)
Alice ve Bob, mesaj 2 KDF'si için dolgu verisini kullanacaktır.
Herhangi bir değiştirilme, bir sonraki mesajın başarısız olmasına neden olacak şekilde kimlik doğrulanır.
Seçenekler bloğu:
Not: Tüm alanlar büyük endian’dır.
+----+----+----+----+----+----+----+----+
| id | ver| padLen | m3p2len | Rsvd(0) |
+----+----+----+----+----+----+----+----+
| tsA | Reserved (0) |
+----+----+----+----+----+----+----+----+
id :: 1 bayt, ağ kimliği (şu anda 2, test ağları hariç)
0.9.42'den itibaren. Öneri 147'ye bakın.
ver :: 1 bayt, protokol sürümü (şu anda 2)
padLen :: 2 bayt, dolgu uzunluğu, 0 veya daha fazla
Minimum/maksimum kılavuzları TBD. 0 ile 31 bayt arasında rastgele boyut mu minimum?
(Dağıtım belirlenecek, Ek A'ya bakın.)
m3p2Len :: 2 bayt, SessionConfirmed'daki ikinci AEAD çerçevesinin uzunluğu
(mesaj 3 bölüm 2) Aşağıdaki notlara bakın
Rsvd :: 2 bayt, gelecekteki seçeneklerle uyumluluk için 0 olarak ayarlanır
tsA :: 4 bayt, Unix zaman damgası, imzasız saniye.
2106'da döner
Reserved :: 4 bayt, gelecekteki seçeneklerle uyumluluk için 0 olarak ayarlanır
Notlar
Yayınlanan adres “NTCP” olduğunda, Bob aynı portta hem NTCP hem de NTCP2’yi destekler. Uyumluluk için, “NTCP” olarak yayınlanan bir adrese bağlantı kurarken Alice, bu mesajın maksimum boyutunu, dolguyu da içermek üzere 287 bayt veya daha az sınırlamalıdır. Bu, Bob tarafından otomatik protokol tanımlamasını kolaylaştırır. “NTCP2” olarak yayınlandığında, boyut sınırlaması yoktur. Aşağıdaki Yayınlanan Adresler ve Sürüm Tespiti bölümlerine bakın.
Başlangıçtaki benzersiz X değeri, her oturum için şifreli metnin farklı olmasını sağlar.
Bob, zaman damgası değeri mevcut zamandan çok uzaksa bağlantıları reddetmelidir. Maksimum delta zamanı “D” olarak adlandırın. Bob, daha önce kullanılan el sıkışma değerlerini yerel bir önbellekte tutmalı ve tekrar oynatma saldırılarını önlemek için yinelenenleri reddetmelidir. Önbellekteki değerlerin ömrü en az 2*D olmalıdır. Önbellek değerleri uygulamaya bağlıdır, ancak 32 baytlık X değeri (veya şifrelenmiş eşdeğeri) kullanılabilir.
Diffie-Hellman geçici anahtarları, kriptografik saldırıları önlemek için asla yeniden kullanılmamalıdır ve tekrar oynatma saldırısı olarak reddedilecektir.
“KE” ve “auth” seçenekleri uyumlu olmalıdır, yani paylaşılan gizli K uygun boyutta olmalıdır. Daha fazla “auth” seçeneği eklenirse, bu “KE” bayrağının anlamını farklı bir KDF veya farklı bir kesme boyutu kullanmak için örtülü olarak değiştirebilir.
Bob, Alice’in geçici anahtarının eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.
Dolgu, makul bir miktara sınırlanmalıdır. Bob, aşırı dolguya sahip bağlantıları reddedebilir. Bob, mesaj 2’de dolgu seçeneklerini belirtecektir. Minimum/maksimum kılavuzları TBD. 0 ile 31 bayt arasında rastgele boyut mu minimum? (Dağıtım belirlenecek, Ek A’ya bakın.)
AEAD, DH, zaman damgası, görünür tekrar oynatma veya anahtar doğrulama hatası dahil herhangi bir hata durumunda, Bob daha fazla mesaj işleme yapmayı durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu, abnormal bir kapanış (TCP RST) olmalıdır. Probing direnci için, AEAD hatası sonrası, Bob rastgele bir zaman aşımı (aralık TBD) ayarlamalı ve ardından soketi kapatmadan önce rastgele bayt sayısı (aralık TBD) okumalıdır.
DoS Azaltma: DH nispeten maliyetli bir işlemdir. Önceki NTCP protokolü gibi, yönlendiriciler CPU veya bağlantı tükenmesini önlemek için gerekli tüm önlemleri almalıdır. Maksimum aktif bağlantılar ve maksimum bağlantı kurulumları ilerlemede sınırlar koyun. Okuma zaman aşımını uygulayın (her okuma için ve “slowloris” için toplam). Aynı kaynaktan tekrarlanan veya eşzamanlı bağlantıları sınırlayın. Tekrarlanan hatalarla birlikte kaynaklar için kara listeler tutun. AEAD hatasına yanıt vermeyin.
Hızlı sürüm tespiti ve el sıkışmayı kolaylaştırmak için, uygulamalar Alice’in ilk mesajın tüm içeriğini, dolguyu da içermek üzere bir kez arabelleğe alıp sonra tamamen boşaltmasını sağlamalıdır. Bu, verinin tek bir TCP paketinde (OS veya ara kutular tarafından parçalanmadığı sürece) yer alması ve Bob tarafından bir seferde alınması olasılığını artırır. Ayrıca, uygulamalar Bob’un ikinci mesajın tüm içeriğini, dolguyu da içermek üzere bir kez arabelleğe alıp sonra tamamen boşaltmasını ve Bob’un üçüncü mesajın tüm içeriğini bir kez arabelleğe alıp sonra tamamen boşaltmasını sağlamalıdır. Bu da verimlilik ve rastgele dolgunun etkinliğini sağlamak içindir.
“ver” alanı: NTCP2’yi belirten genel Gürültü protokolü, uzantılar ve yük spesifikasyonlarını içeren NTCP protokolü. Bu alan, gelecekteki değişikliklerin desteğini belirtmek için kullanılabilir.
Mesaj 3 bölüm 2 uzunluğu: Bu, SessionConfirmed mesajında gönderilecek Alice’in Router Info’sunu ve isteğe bağlı dolguyu içeren ikinci AEAD çerçevesinin boyutudur (16 baytlık MAC dahil). Yönlendiriciler periyodik olarak Router Info’larını yeniden oluşturur ve yeniden yayınlar, bu nedenle mesaj 3 gönderilmeden önce mevcut Router Info boyutu değişebilir. Uygulamalar iki stratejiden birini seçmelidir: a) mesaj 3’te gönderilecek mevcut Router Info’yu kaydetmek, böylece boyut bilinir ve isteğe bağlı olarak dolgu için yer eklemek; b) Router Info boyutunda olası artışı karşılamak için belirtilen boyutu yeterince artırmak ve mesaj 3 gerçekten gönderildiğinde her zaman dolgu eklemek. Her iki durumda da, mesaj 1’de dahil edilen “m3p2len” uzunluğu, mesaj 3’te gönderildiğinde o çerçevenin tam boyutu olmalıdır.
Bob, mesaj 1’i doğruladıktan ve dolguyu okuduktan sonra gelen veri kalırsa bağlantıyı reddetmelidir. Bob henüz mesaj 2 ile yanıt vermediği için Alice’den ekstra veri olmamalıdır.
Ağ kimliği alanı, çapraz ağ bağlantılarını hızlı bir şekilde tanımlamak için kullanılır. Bu alan sıfır değilse ve Bob’un ağ kimliğiyle eşleşmiyorsa, Bob bağlantıyı kesmeli ve gelecekteki bağlantıları engellemelidir. 0.9.42’den itibaren. Daha fazla bilgi için öneri 147’ye bakın.
Anahtar Türetme Fonksiyonu (KDF) (el sıkışma mesajı 2 ve mesaj 3 bölüm 1 için)
// mesaj 1 KDF'sinden kaydedilen h'yi al
// MixHash(şifrelenmiş yük)
h = SHA256(h || mesaj 1'den 32 baytlık şifrelenmiş yük)
// MixHash(dolgu)
// Yalnızca dolgu uzunluğu sıfır değilse
h = SHA256(h || mesaj 1'den rastgele dolgu)
Bu "e" mesaj desenidir:
Bob, geçici DH anahtar çifti e üretir.
// h, el sıkışma mesajı 1 KDF'sinden
// Bob geçici anahtarı Y
// MixHash(e.pubkey)
// || aşağıda ekleme anlamına gelir
h = SHA256(h || e.pubkey);
// h, mesaj 2'deki AEAD için ilişkili veri olarak kullanılır
// Mesaj 3 KDF'si için Hash h'yi sakla
"e" mesaj deseninin sonu.
Bu "ee" mesaj desenidir:
// DH(e, re)
Alice'in geçici anahtarı ile Bob'un geçici anahtarı arasındaki DH sonucunun 32 baytlık input_key_material tanımla
input_key_material = X25519 DH sonucu olarak ayarla
// bellekteki Alice'in geçici anahtarını sıfırla, artık gerekli değil
// Alice:
e(public ve private) = (tüm sıfırlar)
// Bob:
re = (tüm sıfırlar)
// MixKey(DH())
32 baytlık temp_key tanımla
[RFC-2104](https://tools.ietf.org/html/rfc2104) belgesinde tanımlandığı gibi HMAC-SHA256(anahtar, veri) tanımla
// Zincirleme anahtarı ve DH sonucundan geçici bir anahtar üret
// ck, el sıkışma mesajı 1 KDF'sinden gelen zincirleme anahtarıdır
temp_key = HMAC-SHA256(ck, input_key_material)
// bellekteki DH sonucunu sıfırla, artık gerekli değil
input_key_material = (tüm sıfırlar)
// Çıktı 1
// Yeni bir zincirleme anahtarı temp_key'den üret
// byte() aşağıda tek bir bayt anlamına gelir
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Çıktı 2
// Şifre anahtarı k üret
32 baytlık k tanımla
// || aşağıda ekleme anlamına gelir
// byte() aşağıda tek bir bayt anlamına gelir
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// bellekteki temp_key'i sıfırla, artık gerekli değil
temp_key = (tüm sıfırlar)
// mesaj 3 KDF'si için zincirleme anahtarı ck'yi sakla
"ee" mesaj deseninin sonu.
2) SessionCreated
Bob, Alice’e gönderir.
Gürültü içeriği: Bob’un geçici anahtarı Y
Gürültü yükü: 16 baytlık seçenek bloğu
Gürültü dışı yük: Rastgele dolgu
(Yük Güvenlik Özellikleri)
XK(s, rs): Kimlik Doğrulama Gizlilik
<- e, ee 2 1
Kimlik Doğrulama: 2.
Anahtar tehlikeye girme sahtekarlığına (KCI) karşı dirençli gönderen kimlik doğrulaması.
Gönderen kimlik doğrulaması, gönderenin statik anahtar çifti ile alıcının geçici anahtar çifti arasındaki geçici-statik DH ("es" veya "se") temel alınır.
İlgili özel anahtarların güvenli olduğu varsayılırsa, bu kimlik doğrulama sahtekarlıkla oluşturulamaz.
Gizlilik: 1.
Geçici bir alıcıya şifreleme.
Bu yük, geçici-geçici DH ("ee") içerdiği için ileri gizliliğe sahiptir.
Ancak, gönderen alıcıyı kimlik doğrulamamıştır,
bu yüzden bu yük herhangi bir tarafa, dahil olmak üzere aktif bir saldırgana gönderilmiş olabilir.
"e": Bob yeni bir geçici anahtar çifti üretir ve e değişkeninde saklar,
geçici ortak anahtarı açık metin olarak mesaj arabelleğine yazar,
ve eski h ile birlikte ortak anahtarı hashleyerek yeni bir h türetir.
"ee": Bob'un geçici anahtar çifti ile Alice'in geçici anahtar çifti arasında bir DH gerçekleştirilir.
Sonuç, eski ck ile birlikte hashlenerek yeni bir ck ve k türetilir ve n sıfıra ayarlanır.
Y değeri, yükün ayırt edilemezliğini ve benzersizliğini sağlamak için şifrelenir, bu gerekli DPI karşı önlemlerdir. Bu amaçla AES şifrelemesi kullanıyoruz, elligator2 gibi daha karmaşık ve yavaş alternatifler yerine. Alice’in yönlendirici ortak anahtarına asimetrik şifreleme çok yavaştır. AES şifreleme, Bob’un yönlendirici hash’ini anahtar olarak ve mesaj 1’deki AES durumunu (ağ veritabanında yayınlandığı gibi Bob’un IV’siyle başlatılmıştır) kullanır.
AES şifreleme yalnızca DPI direnci içindir. Ağ veritabanında yayınlandığı için Bob’un yönlendirici hash’ini ve IV’sini bilen ve mesaj 1’in ilk 32 baytını yakalayan herhangi bir taraf, bu mesajdaki Y değerini çözebilir.
Ham içerikler:
+----+----+----+----+----+----+----+----+
| |
+ RH_B ile gizlenmiş +
| AES-CBC-256 şifrelenmiş Y |
+ (32 bayt) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| ChaChaPoly çerçeve |
+ Şifrelenmiş ve kimlik doğrulanan veri +
| 32 bayt |
+ k mesaj 2 KDF'siyle tanımlanır +
| n = 0; ilişkili veri için KDF'ye bakın |
+ +
| |
+----+----+----+----+----+----+----+----+
| şifrelenmemiş kimlik doğrulanan |
+ dolgu (isteğe bağlı) +
| uzunluk seçenekler bloğunda tanımlanır |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bayt, AES-256-CBC şifrelenmiş X25519 geçici anahtarı, little endian
anahtar: RH_B
iv: Mesaj 1'deki AES durumu kullanılarak
Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmez):
+----+----+----+----+----+----+----+----+
| |
+ +
| Y |
+ (32 bayt) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| seçenekler |
+ (16 bayt) +
| |
+----+----+----+----+----+----+----+----+
| şifrelenmemiş kimlik doğrulanan |
+ dolgu (isteğe bağlı) +
| uzunluk seçenekler bloğunda tanımlanır |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bayt, X25519 geçici anahtarı, little endian
seçenekler :: seçenekler bloğu, 16 bayt, aşağıya bakın
dolgu :: Rastgele veri, 0 veya daha fazla bayt.
Toplam mesaj uzunluğu 65535 bayt veya daha az olmalıdır.
Alice ve Bob, mesaj 3 bölüm 1 KDF'si için dolgu verisini kullanacaktır.
Herhangi bir değiştirilme, bir sonraki mesajın başarısız olmasına neden olacak şekilde kimlik doğrulanır.
Notlar
Alice, Bob’un geçici anahtarının eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.
Dolgu, makul bir miktara sınırlanmalıdır. Alice, aşırı dolguya sahip bağlantıları reddedebilir. Alice, mesaj 3’te dolgu seçeneklerini belirtecektir. Minimum/maksimum kılavuzları TBD. 0 ile 31 bayt arasında rastgele boyut mu minimum? (Dağıtım belirlenecek, Ek A’ya bakın.)
AEAD, DH, zaman damgası, görünür tekrar oynatma veya anahtar doğrulama hatası dahil herhangi bir hata durumunda, Alice daha fazla mesaj işleme yapmayı durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır. Bu, abnormal bir kapanış (TCP RST) olmalıdır.
Hızlı el sıkışmayı kolaylaştırmak için, uygulamalar Bob’un ilk mesajın tüm içeriğini, dolguyu da içermek üzere bir kez arabelleğe alıp sonra tamamen boşaltmasını sağlamalıdır. Bu, verinin tek bir TCP paketinde (OS veya ara kutular tarafından parçalanmadığı sürece) yer alması ve Alice tarafından bir seferde alınması olasılığını artırır. Bu da verimlilik ve rastgele dolgunun etkinliğini sağlamak içindir.
Alice, mesaj 2’yi doğruladıktan ve dolguyu okuduktan sonra gelen veri kalırsa bağlantıyı reddetmelidir. Alice henüz mesaj 3 ile yanıt vermediği için Bob’dan ekstra veri olmamalıdır.
Seçenekler bloğu:
Not: Tüm alanlar büyük endian’dır.
+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen | Reserved (0) |
+----+----+----+----+----+----+----+----+
| tsB | Reserved (0) |
+----+----+----+----+----+----+----+----+
Reserved :: toplam 10 bayt, gelecekteki seçeneklerle uyumluluk için 0 olarak ayarlanır
padLen :: 2 bayt, büyük endian, dolgu uzunluğu, 0 veya daha fazla
Minimum/maksimum kılavuzları TBD. 0 ile 31 bayt arasında rastgele boyut mu minimum?
(Dağıtım belirlenecek, Ek A'ya bakın.)
tsB :: 4 bayt, büyük endian, Unix zaman damgası, imzasız saniye.
2106'da döner
Notlar
- Alice, zaman damgası değeri mevcut zamandan çok uzaksa bağlantıları reddetmelidir. Maksimum delta zamanı “D” olarak adlandırın. Alice, daha önce kullanılan el sıkışma değerlerini yerel bir önbellekte tutmalı ve tekrar oynatma saldırılarını önlemek için yinelenenleri reddetmelidir. Önbellekteki değerlerin ömrü en az 2*D olmalıdır. Önbellek değerleri uygulamaya bağlıdır, ancak 32 baytlık Y değeri (veya şifrelenmiş eşdeğeri) kullanılabilir.
Sorunlar
- Buraya min/max dolgu seçenekleri dahil edilsin mi?
El sıkışma mesajı 3 bölüm 1 için şifreleme (mesaj 2 KDF’si kullanılarak)
// mesaj 2 KDF'sinden kaydedilen h'yi al
// MixHash(şifrelenmiş yük)
h = SHA256(h || mesaj 2'den 24 baytlık şifrelenmiş yük)
// MixHash(dolgu)
// Yalnızca dolgu uzunluğu sıfır değilse
h = SHA256(h || mesaj 2'den rastgele dolgu)
// h, aşağıda mesaj 3 bölüm 1'deki AEAD için ilişkili veri olarak kullanılır
Bu "s" mesaj desenidir:
32 baytlık Alice'in statik ortak anahtarı s tanımla
// EncryptAndHash(s.publickey)
// EncryptWithAd(h, s.publickey)
// AEAD_ChaCha20_Poly1305(anahtar, nonce, ilişkiliVeri, veri)
// k el sıkışma mesajı 1'den
// n 1'dir
şifreli_metin = AEAD_ChaCha20_Poly1305(k, n++, h, s.publickey)
// MixHash(şifreli_metin)
// || aşağıda ekleme anlamına gelir
h = SHA256(h || şifreli_metin);
// h, mesaj 3 bölüm 2'deki AEAD için ilişkili veri olarak kullanılır
"s" mesaj deseninin sonu.
Anahtar Türetme Fonksiyonu (KDF) (el sıkışma mesajı 3 bölüm 2 için)
Bu "se" mesaj desenidir:
// DH(s, re) == DH(e, rs)
Alice'in statik anahtarı ile Bob'un geçici anahtarı arasındaki DH sonucunun 32 baytlık input_key_material tanımla
input_key_material = X25519 DH sonucu olarak ayarla
// bellekteki Bob'un geçici anahtarını sıfırla, artık gerekli değil
// Alice:
re = (tüm sıfırlar)
// Bob:
e(public ve private) = (tüm sıfırlar)
// MixKey(DH())
32 baytlık temp_key tanımla
[RFC-2104](https://tools.ietf.org/html/rfc2104) belgesinde tanımlandığı gibi HMAC-SHA256(anahtar, veri) tanımla
// Zincirleme anahtarı ve DH sonucundan geçici bir anahtar üret
// ck, el sıkışma mesajı 1 KDF'sinden gelen zincirleme anahtarıdır
temp_key = HMAC-SHA256(ck, input_key_material)
// bellekteki DH sonucunu sıfırla, artık gerekli değil
input_key_material = (tüm sıfırlar)
// Çıktı 1
// Yeni bir zincirleme anahtarı temp_key'den üret
// byte() aşağıda tek bir bayt anlamına gelir
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Çıktı 2
// Şifre anahtarı k üret
32 baytlık k tanımla
// || aşağıda ekleme anlamına gelir
// byte() aşağıda tek bir bayt anlamına gelir
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// mesaj 3 bölüm 1'den h, mesaj 3 bölüm 2'deki AEAD için ilişkili veri olarak kullanılır
// EncryptAndHash(yük)
// EncryptWithAd(h, yük)
// AEAD_ChaCha20_Poly1305(anahtar, nonce, ilişkiliVeri, veri)
// n 0'dır
şifreli_metin = AEAD_ChaCha20_Poly1305(k, n++, h, yük)
// MixHash(şifreli_metin)
// || aşağıda ekleme anlamına gelir
h = SHA256(h || şifreli_metin);
// veri aşaması KDF'si için zinc