İki ad da AEAD yapılarıdır, ikisi de standartlaştırılmıştır ve güncel bir x86 sunucusunda her biri görünür bir çaba olmadan bir gigabit bağlantıyı doyurur. Seçim, o sunucudan ayrıldığınızda keyfî olmaktan çıkar: ucuz yönlendiriciler, eski telefonlar ve sanal cihazlar çoğu zaman AES hızlandırmasına sahip değildir ve orada fark büyüktür. Yani karşılaştırma hangi şifrenin daha hızlı olduğu değil, hangi şifrenin bu uç nokta kümesinde iyi çalıştığı ve protokolün bir seçenek sunup sunmadığıdır.

Aynı iş, farklı çekirdekler

Her iki yapı da tek geçişte gizlilik ve bütünlük sağlar ve ilişkili veriyi doğrular, bu yüzden VPN protokolleri onları veri kanalı için kullanır. Fark içeridedir: AES-GCM, GF(2^128) üzerinde polinom kimlik doğrulayıcılı sayaç kipinde AES blok şifresidir; ChaCha20-Poly1305 ise 256 bit anahtarlı bir akış şifresi ve ayrı bir tek kullanımlık doğrulayıcıdır.

Operasyonel olarak önemli olan ortaktır: ikisi de nonce yeniden kullanımında feci biçimde başarısız olur, ikisi de her anahtar için nonce alanının yönetimini gerektirir ve hiçbiri yanlış şeyi doğrulayan bir eşi düzeltmez. AES-256-GCM diyen bir profil CHACHA20-POLY1305 diyenden daha güvenli değildir; uygulama doğru olduğunda ikisi de güçlüdür.

AES-GCM nerede kazanır

AES çoğu modern CPU'da özel talimatlara sahiptir: x86'da AES-NI, ARMv8'de kripto uzantıları ve yeni POWER ile RISC-V tasarımlarında eşdeğerleri. Bunlar varsa GCM her çevrim sınıfında birkaç bloğu paralel çalıştırır ve yazılım uygulaması önemsizleşir. Bu, sunucular, masaüstü bilgisayarlar ve güncel telefonlar için olağan durumdur ve bu yüzden veri merkezinde AES kullanma tavsiyesi makul bir varsayılandır.

Sorun ikinci dereceden durumdur. Özel talimatlar olmadan AES yazılımda yavaştır ve tablo tabanlı yazılım uygulamaları uzun bir önbellek zamanlaması sorunu geçmişine sahip olanlardır. Ana makinesinin konuğa AES bayraklarını göstermediği bir sanal makinede çalışan VPN yoğunlaştırıcısı tam olarak bu durumdur ve ana makinenin CPU'sunda özellik olduğu için kolayca gözden kaçar.

CPU'nun neyi desteklediğini değil, sürecin gerçekte ne gördüğünü kontrol edin: Linux'ta grep -o aes /proc/cpuinfo | head -1 veya hipervizörün CPU modelindeki eşdeğer özellik bayrağı.

ChaCha20-Poly1305 nerede kazanır

ChaCha20 taşınabilir yazılımda hızlıdır çünkü yalnızca toplama, döndürme ve XOR kullanır ve uygulamaları tasarım gereği sırra bağlı tablo aramalarından kaçınır. AES hızlandırması olmayan bir cihazda bu maddi bir avantajdır ve WireGuard bu yüzden onu seçti: WireGuard protokol açıklaması ChaCha20-Poly1305'i alternatifsiz veri şifresi olarak listeler.

Bu tek seçim yararlı bir şey söyler: AES'in hızlandırıldığı donanımda WireGuard, AES-GCM'ye kıyasla bir miktar verimden vazgeçer ve yazarları bunu telefonlarda, ev yönlendiricilerinde ve konteyner ana makinelerinde öngörülebilir davranış karşılığında kabul etti. Filonuz çoğunlukla küçük ARM kutularıysa bu takas sizin lehinizedir.

Ters durum yoğun bir x86 yoğunlaştırıcısıdır; orada AES-NI ile AES-GCM daha hızlı ve daha iyi desteklenen yoldur ve ChaCha20 her gigabit için ölçülebilir CPU harcar. Hiçbir yapı zayıflık değildir; soru donanımınızın hangisini ucuza yürüttüğüdür.

Protokolünüzün gerçekte neyi seçmenize izin verdiği

ProtocolWhat you get
WireGuardChaCha20-Poly1305 only; no negotiation
OpenVPN 2.5 and laterData channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305
IPsec / IKEv2AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it
OpenVPN control channelTLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites

OpenVPN'deki ayrımı fark edin: kontrol kanalı ve veri kanalı ayrı ayrı müzakere edilir, bu yüzden TLS için gördüğünüz takım yükünüzü koruyan şifre hakkında hiçbir şey söylemez. Oturum özeti ikisini de bildirir ve ikisinden yalnızca birini okumak yaygın bir karışıklık kaynağıdır.

OpenVPN'de veri kanalının şifresi her iki uçtaki data-ciphers listesinden gelir. Sunucunun listesi ile istemcinin listesi kesişmezse bağlantı ya data-ciphers-fallback izin verdiğine geri döner ya da tamamen başarısız olur ve bu başarısızlık genellikle yanlış katmana yüklenir. Aynı listeyi iki tarafa koyun, sonra listenin sırasına uyulduğunu varsaymak yerine müzakere edilen sonucu günlükte doğrulayın.

Dağıtım hakkında üç olgudan karar verin

Birincisi, uç noktalarda AES hızlandırması var mı? Her eşte varsa AES-GCM daha ucuz seçimdir ve bakımı yapılan yapılandırmaların çoğunda varsayılandır. Önemli bir bölümü küçük yönlendiriciler veya eski telefonlarsa ChaCha20-Poly1305, filonun kuyruğunun kapasite sınırı olmasını önler.

İkincisi, protokol bir seçenek sunuyor mu? WireGuard'da karar sizin yerinize verilmiştir ve yararlı iş, etrafındaki araçların sessizce başka bir şey koymadığını doğrulamaktır. OpenVPN ve IPsec'te yanıt bir yapılandırma satırı ve kaydedilmesi gereken müzakere edilmiş sonuçtur.

Üçüncüsü, iki uç anlaşabilir mi? Bir eşin uygulamadığı şifre performans kararı değil, kesintidir. Bu yüzden eş listesi herhangi bir kıyaslamadan daha önemlidir: karma bir filo yeteneklerin kesişimine ihtiyaç duyar, en hızlı makinenin tercihine değil.

Ölçerseniz cihazı, uç noktayı ve yükü aynı tutun ve tek bir şeyi değiştirin. Farklı bölgelerdeki iki sunucuyu karşılaştıran test rotayı ölçer, şifreyi değil ve dizüstü bilgisayardaki bir ölçüm, CPU bayrakları maskelenmiş bir konteyner ana makinesi hakkında hiçbir şey söylemez. Karşılaştırın, sonra gerçekte hangi şifrenin müzakere edildiğini yazın: o kayıt kıyaslamadan daha değerlidir.

İlgili makaleler