CFB1 mot CFB8 mot CFB128: det är storleken på återkopplingen, inte på nyckeln

Ett namn som AES-256-CFB1 bär två tal, och de svarar på olika frågor. 256 är AES-nyckelns längd. 1 är CFB-återkopplingen, alltså segmentstorleken, en egenskap för hur läget flyttar sitt tillstånd. Läser man 1 som en nyckellängd ser namnet ut som en katastrofal felkonfiguration, och därför kommer frågan ständigt tillbaka.

Avgör vilken av tre storheter du tittar på innan du bedömer namnet: nyckelstorlek, blockstorlek eller segmentstorlek. Bara den första är en säkerhetsparameter i vanlig mening.

Tre tal, tre storheter

AES tar emot 128, 192 eller 256-bitars nycklar och har ett 128-bitars block oavsett vad du väljer. Blockstorleken tillhör AES, inte läget. CFB-suffixet är den tredje storheten: hur mycket data läget förbrukar och matar tillbaka per steg. OpenSSL:s AES-dokumentation listar dessa skiftstorlekar uttryckligen för CFB-varianterna.

CFB1 matar tillbaka en bit i taget, CFB8 en byte, CFB128 ett helt block. Alla tre använder samma 128-bitars blockchiffer internt; det som ändras är hur många bitar av varje beräknat block som används per operation. Därför flyttar suffixet kostnad och buffertbeteende, inte nyckelstyrka.

Varför blockstorleken aldrig ändras

AES är ett blockchiffer med ett fast 128-bitars block, och lägen är konstruktioner byggda runt det. Ingen av dem krymper blocket för att matcha segmentstorleken. En CFB1-implementering beräknar fortfarande ett helt AES-block och tar en bit av resultatet. De andra bitarna kastas för det steget, och det är precis där effektivitetskostnaden ligger.

Så en enbits återkoppling innebär inte en enbits nyckel, och ett namn kan inte rangordnas efter suffixet. CFB128 är inte fyra gånger starkare än CFB32; det bearbetar större segment.

Vad segmentstorleken faktiskt ändrar

Segmentstorleken ändrar hur mycket chiffertext som matas tillbaka per steg och hur mycket klartext varje steg kan bära. Den ändrar också felutbredning och buffertbeteende, vilket spelar roll för strömliknande användning. Byteorienterade segment passar med buffertar, bitorienterade gör det inte.

I praktiken väljer protokollet läget, inte operatören. En VPN-datakanal använder den konstruktion som protokollet föreskriver, med sitt eget integritetsskydd, och en bibliotekslista berättar bara vilka namn som finns.

Att läsa en okvalificerad CFB-etikett

En okvalificerad CFB-etikett behöver sitt implementeringssammanhang. I OpenSSL 1.0.2-rubrikerna är EVP_aes_128_cfb ett makro för EVP_aes_128_cfb128, med matchande alias för 192- och 256-bitarsnycklar. Det är en API-namngivningskonvention från en gren, inte ett påstående att varje bibliotek, filformat eller GUI expanderar förkortningen på samma sätt. Kontrollera rubriken eller dokumentationen för den version du har framför dig.

Om en äldre profil säger CFB och motparten accepterar det, registreras de förhandlade parametrarna någonstans: i en logg, en konfigurationsdump, ett API-svar. Läs dem i stället för att härleda segmentstorleken ur en visningssträng.

Vad ett lägesnamn inte berättar

Namnet beskriver krypteringsbeteende och ingenting annat. En VPN behöver fortfarande integritetsskydd, nyckelhärledning och motpartsauth, och CFB levererar inget av det. Att byta CFB8 mot CFB1 är inte heller en kosmetisk ändring: beteendet på tråden skiljer sig och båda sidor måste stödja samma konstruktion. Inte heller bevisar ett namn i ett bibliotek att den utrullade gatewayen accepterar det för sin datakanal.

För allt som underhålls, använd protokollets fullständiga skyddsupplägg och operatörens policy, och registrera biblioteks- och gatewayversioner, det exakta alternativet och det förhandlade resultatet. Det gamla namnet förklarar vad du läser; det motiverar inte att återuppliva konfigurationen.