Egy AES-256-CFB1 típusú név két számot hordoz, és ezek különböző kérdésekre válaszolnak. A 256 az AES-kulcs hossza. Az 1 pedig a CFB visszacsatolása, vagyis a szegmens mérete: annak tulajdonsága, hogyan lépteti előre állapotát a mód. Ha az 1-et kulcshosszként olvassuk, a név katasztrofális hibás konfigurációnak tűnik, és ezért tér vissza újra meg újra a kérdés.

Döntse el, melyik három mennyiséget nézi, mielőtt megítéli a nevet: kulcsméret, blokkméret vagy szegmensméret. Csak az első biztonsági paraméter a szokásos értelemben.

Három szám, három mennyiség

Az AES 128, 192 vagy 256 bites kulcsokat fogad el, és bármelyiket választja, 128 bites a blokkja. A blokkméret az AES-hez tartozik, nem a módhoz. A CFB utótag a harmadik mennyiség: mennyi adatot fogyaszt és ad vissza a mód lépésenként. Az OpenSSL AES-dokumentációja kifejezetten felsorolja ezeket az eltolási méreteket a CFB-változatokhoz.

A CFB1 egyszerre egy bitet ad vissza, a CFB8 egy bájtot, a CFB128 egy teljes blokkot. Mindhárom belül ugyanazt a 128 bites blokk-rejtjelezőt használja; az változik, hogy minden kiszámított blokkból hány bitet használ műveletenként. Ezért az utótag inkább a költséget és a pufferelési viselkedést mozgatja, mint a kulcs erejét.

NameKeyAES blockFeedback
AES-256-CFB1256 bits128 bits1 bit
AES-256-CFB8256 bits128 bits8 bits
AES-256-CFB128256 bits128 bits128 bits

Miért nem változik soha a blokkméret

Az AES fix 128 bites blokkal rendelkező blokk-rejtjelező, a módok pedig köré épülő konstrukciók. Egyik sem zsugorítja a blokkot, hogy illeszkedjen a szegmens méretéhez. A CFB1 implementációja továbbra is egy teljes AES-blokkot számít ki, és egy bitet vesz az eredményből. A többi bitet arra a lépésre eldobják, és pontosan ott van a hatékonysági költség.

Az egybites visszacsatolás tehát nem jelent egybites kulcsot, és egy név nem rangsorolható az utótagja szerint. A CFB128 nem négyszer erősebb a CFB32-nél; nagyobb szegmenseket dolgoz fel.

Mit változtat valójában a szegmensméret

A szegmensméret megváltoztatja, mennyi rejtjelezett szöveget ad vissza a rendszer lépésenként, és mennyi nyílt szöveget tud hordozni egy lépés. Megváltoztatja a hibaterjedést és a pufferelési viselkedést is, ami számít a folyamszerű használatban. A bájtorientált szegmensek illeszkednek a pufferekhez, a bitorientáltak nem.

A gyakorlatban a protokoll választja a módot, nem az üzemeltető. Egy VPN-adatcsatorna azt a konstrukciót használja, amelyet a protokollja előír, saját integritásvédelemmel, és egy könyvtárlistából csak az derül ki, milyen nevek léteznek.

Minősítés nélküli CFB-címke olvasása

Egy minősítés nélküli CFB-címke megkívánja a megvalósítási környezetét. Az OpenSSL 1.0.2 fejléceiben az EVP_aes_128_cfb makró az EVP_aes_128_cfb128-hoz, a 192 és 256 bites kulcsokhoz tartozó megfelelő álnevekkel. Ez egy ág API-elnevezési konvenciója, nem annak állítása, hogy minden könyvtár, fájlformátum vagy GUI ugyanúgy oldja fel a rövidítést. Ellenőrizze az előtte lévő verzió fejlécét vagy dokumentációját.

Ha egy régi profil CFB-t mond, és a partner elfogadja, a kialkudott paraméterek valahol rögzítésre kerülnek: naplóban, konfigurációkiírásban, API-válaszban. Ezeket olvassa, ahelyett hogy a szegmensméretre egy megjelenítési karakterláncból következtetne.

Amit egy mód neve nem mond el

A név a titkosítás viselkedését írja le, és semmi mást. Egy VPN-nek továbbra is szüksége van integritásvédelemre, kulcslevezetésre és a partner hitelesítésére, és a CFB egyiket sem nyújtja. A CFB8 lecserélése CFB1-re szintén nem kozmetikai változás: a hálózati viselkedés eltér, és mindkét félnek ugyanazt a konstrukciót kell támogatnia. Az sem bizonyíték egy könyvtárban szereplő név, hogy a telepített átjáró elfogadja az adatcsatornájához.

Minden karbantartott dologhoz használja a protokoll teljes védelmi elrendezését és az üzemeltető szabályzatát, és rögzítse a könyvtár és az átjáró verzióit, a pontos beállítást és a kialkudott eredményt. A régi név megmagyarázza, mit olvas; nem igazolja a konfiguráció újraélesztését.

Kapcsolódó cikkek