CFB1, CFB8 ja CFB128: kyse on takaisinkytkennän koosta, ei avaimen koosta

Nimi kuten AES-256-CFB1 kantaa kaksi lukua, ja ne vastaavat eri kysymyksiin. 256 on AES-avaimen pituus. Ja 1 on CFB:n takaisinkytkentä eli segmentin koko: ominaisuus siitä, miten tila kuljettaa tilaansa eteenpäin. Jos 1 luetaan avaimen pituudeksi, nimi näyttää katastrofaaliselta väärältä kokoonpanolta, ja siksi kysymys palaa yhä uudelleen.

Päätä, mitä kolmesta suureesta katsot, ennen kuin arvioit nimeä: avaimen koko, lohkon koko vai segmentin koko. Vain ensimmäinen on turvaparametri tavanomaisessa mielessä.

Kolme lukua, kolme suuretta

AES hyväksyy 128, 192 tai 256 bitin avaimet ja sen lohko on 128 bittiä valitsitpa mitä tahansa. Lohkon koko kuuluu AES:lle, ei tilalle. CFB-pääte on kolmas suure: kuinka paljon dataa tila kuluttaa ja syöttää takaisin kullakin askeleella. OpenSSL:n AES-dokumentaatio luettelee nämä siirtymäkoot nimenomaisesti CFB-muunnelmille.

CFB1 syöttää takaisin yhden bitin kerrallaan, CFB8 yhden tavun, CFB128 kokonaisen lohkon. Kaikki kolme käyttävät sisäisesti samaa 128 bitin lohkosalainta; se muuttuu, kuinka monta bittiä kustakin lasketusta lohkosta käytetään operaatiota kohden. Siksi pääte siirtää kustannusta ja puskurointikäyttäytymistä, ei avaimen vahvuutta.

Miksi lohkon koko ei koskaan muutu

AES on lohkosalain, jolla on kiinteä 128 bitin lohko, ja tilat ovat sen ympärille rakennettuja konstruktioita. Mikään niistä ei kutista lohkoa segmentin kokoon sopivaksi. CFB1-toteutus laskee edelleen kokonaisen AES-lohkon ja ottaa tuloksesta yhden bitin. Muut bitit hylätään kyseisellä askeleella, ja juuri siinä tehokkuuskustannus on.

Yhden bitin takaisinkytkentä ei siis tarkoita yhden bitin avainta, eikä nimeä voi järjestää sen päätteen mukaan. CFB128 ei ole neljä kertaa vahvempi kuin CFB32; se käsittelee suurempia segmenttejä.

Mitä segmentin koko todella muuttaa

Segmentin koko muuttaa sitä, kuinka paljon salatekstiä syötetään takaisin askeleella ja kuinka paljon selväkstiä kukin askel voi kuljettaa. Se muuttaa myös virheiden leviämistä ja puskurointikäyttäytymistä, millä on merkitystä virran kaltaisessa käytössä. Tavuihin suuntautuvat segmentit asettuvat puskureihin, bittipohjaiset eivät.

Käytännössä tilan valitsee protokolla, ei ylläpitäjä. VPN:n datakanava käyttää konstruktiota, jonka sen protokolla määrää, omalla eheyssuojallaan, ja kirjastoluettelo kertoo vain, mitkä nimet ovat olemassa.

Määrittelemättömän CFB-tunnisteen lukeminen

Määrittelemätön CFB-tunniste tarvitsee toteutuskontekstinsa. OpenSSL 1.0.2:n otsakoissa EVP_aes_128_cfb on makro EVP_aes_128_cfb128:lle, ja vastaavat aliakset ovat 192 ja 256 bitin avaimille. Tämä on yhden haaran API-nimikäytäntö, ei väite, että jokainen kirjasto, tiedostomuoto tai GUI laajentaa lyhenteen samalla tavalla. Tarkista edessäsi olevan version otsakko tai dokumentaatio.

Jos vanha profiili sanoo CFB ja vastapuoli hyväksyy sen, neuvotellut parametrit kirjataan jonnekin: lokiin, kokoonpanon vedokseen, API-vastaukseen. Lue ne sen sijaan, että päättelet segmentin koon näyttömerkkijonosta.

Mitä tilan nimi ei kerro sinulle

Nimi kuvaa salauskäyttäytymistä eikä muuta. VPN tarvitsee edelleen eheyssuojaa, avaimen johtamista ja vastapuolen todennuksen, eikä CFB tarjoa mitään niistä. Myöskään CFB8:n vaihtaminen CFB1:een ei ole kosmeettinen muutos: käyttäytyminen verkossa eroaa ja molempien osapuolten on tuettava samaa konstruktiota. Eikä kirjastossa oleva nimi todista, että käyttöön otettu yhdyskäytävä hyväksyy sen datakanavalleen.

Kaikessa ylläpidettävässä käytä protokollan täydellistä suojausjärjestelyä ja ylläpitäjän käytäntöä ja kirjaa kirjaston ja yhdyskäytävän versiot, tarkka valinta ja neuvoteltu tulos. Vanha nimi selittää, mitä luet; se ei oikeuta kokoonpanon herättämistä henkiin.