CFB1, CFB8 ve CFB128: bu geri besleme boyutudur, anahtar boyutu değil
CFB'den sonraki sayı bir geri besleme adımıdır, anahtar uzunluğu değil: CFB1, CFB8 ve CFB128 aynı 128 bitlik bloğu kullanır. Eski adları zayıf anahtarlar uydurmadan okuyun.
AES-256-CFB1 gibi bir ad iki sayı taşır ve bunlar farklı soruları yanıtlar. 256, AES anahtarının uzunluğudur. 1 ise CFB geri beslemesi, yani segment boyutu, kipin durumunu nasıl ilerlettiğine dair bir özelliktir. 1 anahtar uzunluğu olarak okunursa ad feci bir yanlış yapılandırma gibi görünür; bu soru bu yüzden tekrar tekrar geri döner.
Adı yargılamadan önce üç büyüklükten hangisine baktığınıza karar verin: anahtar boyutu, blok boyutu veya segment boyutu. Her zamanki anlamda güvenlik parametresi yalnızca ilkidir.
Üç sayı, üç büyüklük
AES 128, 192 veya 256 bitlik anahtarları kabul eder ve hangisini seçerseniz seçin 128 bitlik bir bloğu vardır. Blok boyutu kipe değil AES'e aittir. CFB son eki üçüncü büyüklüktür: kipin her adımda ne kadar veri tükettiği ve geri verdiği. OpenSSL AES belgeleri bu kaydırma boyutlarını CFB türevleri için açıkça listeler.
CFB1 her seferinde bir bit, CFB8 bir bayt, CFB128 tam bir blok geri verir. Üçü de içeride aynı 128 bitlik blok şifreleyicisini kullanır; değişen, hesaplanan her bloktan işlem başına kaç bit kullanıldığıdır. Bu yüzden son ek anahtar gücünü değil maliyeti ve tamponlama davranışını değiştirir.
| Name | Key | AES block | Feedback |
|---|---|---|---|
| AES-256-CFB1 | 256 bits | 128 bits | 1 bit |
| AES-256-CFB8 | 256 bits | 128 bits | 8 bits |
| AES-256-CFB128 | 256 bits | 128 bits | 128 bits |
Blok boyutu neden hiç değişmez
AES sabit 128 bitlik bloğu olan bir blok şifreleyicisidir ve kipler onun etrafına kurulmuş yapılardır. Hiçbiri bloğu segment boyutuna uydurmak için küçültmez. Bir CFB1 uygulaması yine tam bir AES bloğu hesaplar ve sonuçtan bir bit alır. Diğer bitler o adım için atılır; verimlilik maliyeti tam olarak buradadır.
Yani bir bitlik geri besleme bir bitlik anahtar anlamına gelmez ve bir ad son ekine göre sıralanamaz. CFB128, CFB32'den dört kat daha güçlü değildir; daha büyük segmentleri işler.
Segment boyutu gerçekte neyi değiştirir
Segment boyutu her adımda ne kadar şifreli metnin geri verildiğini ve her adımın ne kadar açık metin taşıyabildiğini değiştirir. Hata yayılımını ve tamponlama davranışını da değiştirir; bu, akış benzeri kullanım için önemlidir. Bayt odaklı segmentler tamponlarla hizalanır, bit odaklı olanlar hizalanmaz.
Pratikte kipi protokol seçer, operatör değil. Bir VPN veri kanalı protokolünün belirlediği yapıyı kendi bütünlük korumasıyla kullanır ve bir kütüphane listesi yalnızca hangi adların var olduğunu söyler.
Niteliksiz bir CFB etiketini okumak
Niteliksiz bir CFB etiketi uygulama bağlamına ihtiyaç duyar. OpenSSL 1.0.2 başlıklarında EVP_aes_128_cfb, EVP_aes_128_cfb128 için bir makrodur ve 192 ile 256 bitlik anahtarlar için eşleşen takma adlar vardır. Bu, tek bir daldan gelen bir API adlandırma kuralıdır; her kütüphanenin, dosya biçiminin veya GUI'nin kısaltmayı aynı şekilde açtığı iddiası değildir. Önünüzdeki sürümün başlığını veya belgelerini kontrol edin.
Eski bir profil CFB diyorsa ve karşı taraf kabul ediyorsa, anlaşılan parametreler bir yere kaydedilir: bir günlüğe, bir yapılandırma dökümüne, bir API yanıtına. Segment boyutunu görüntü dizesinden çıkarmak yerine bunları okuyun.
Bir kip adının size söylemedikleri
Ad yalnızca şifreleme davranışını anlatır, başka bir şeyi değil. VPN hâlâ bütünlük koruması, anahtar türetme ve karşı taraf kimlik doğrulaması gerektirir ve CFB bunların hiçbirini sağlamaz. CFB8'i CFB1 ile değiştirmek de kozmetik bir değişiklik değildir: hat üzerindeki davranış farklıdır ve iki taraf da aynı yapıyı desteklemek zorundadır. Bir kütüphanedeki ad, kurulu ağ geçidinin bunu kendi veri kanalı için kabul ettiğini de kanıtlamaz.
Bakımı yapılan her şey için protokolün eksiksiz koruma düzenini ve operatörün politikasını kullanın; kütüphane ve ağ geçidi sürümlerini, tam seçeneği ve anlaşılan sonucu kaydedin. Eski ad ne okuduğunuzu açıklar; yapılandırmayı canlandırmayı haklı çıkarmaz.