CFB1 mot CFB8 mot CFB128: det er storleiken på tilbakemeldinga, ikkje på nøkkelen
Talet etter CFB er eit tilbakemeldingssteg, ikkje ei nøkkellengd: CFB1, CFB8 og CFB128 brukar ein 128-bits blokk. Les gamle namn utan å finne opp svake nøklar.
Eit namn som AES-256-CFB1 ber to tal, og dei svarar på ulike spørsmål. 256 er AES-nøkkellengda. 1 er CFB-tilbakemeldinga, altså segmentstorleiken, ein eigenskap ved korleis modusen flyttar tilstanden sin. Les ein 1 som ei nøkkellengd, ser namnet ut som ein katastrofal feilkonfigurasjon, og difor kjem spørsmålet stadig att.
Avgjer kva for ein av tre storleikar du ser på før du vurderer namnet: nøkkelstorleik, blokkstorleik eller segmentstorleik. Berre den første er ein tryggleiksparameter i vanleg tyding.
Tre tal, tre storleikar
AES godtek 128, 192 eller 256-bits nøklar og har ei 128-bits blokk same kva du vel. Blokkstorleiken høyrer til AES, ikkje til modusen. CFB-suffikset er den tredje storleiken: kor mykje data modusen brukar og fører attende per steg. OpenSSL AES-dokumentasjon listar desse skiftestorleikane eksplisitt for CFB-variantane.
CFB1 fører attende éin bit om gongen, CFB8 éin byte, CFB128 ei heil blokk. Alle tre brukar same 128-bits blokksifferet internt; det som endrar seg, er kor mange bitar av kvar utrekna blokk som vert brukte per operasjon. Difor flyttar suffikset kostnad og bufferatferd, ikkje nøkkelstyrke.
| 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 |
Kvifor blokkstorleiken aldri endrar seg
AES er eit blokksiffer med ei fast 128-bits blokk, og modus er konstruksjonar bygde rundt henne. Ingen av dei krympar blokka for å passe segmentstorleiken. Ein CFB1-implementasjon reknar framleis ut ei full AES-blokk og tek éin bit av resultatet. Dei andre bitane vert kasta for det steget, og det er nettopp der effektivitetskostnaden ligg.
Så ei tilbakemelding på éin bit tyder ikkje ein nøkkel på éin bit, og eit namn kan ikkje rangerast etter suffikset. CFB128 er ikkje fire gonger sterkare enn CFB32; ho handsamar større segment.
Kva segmentstorleiken faktisk endrar
Segmentstorleiken endrar kor mykje siffertekst som vert ført attende per steg, og kor mykje klartekst kvart steg kan bera. Han endrar òg feilforplantning og bufferatferd, noko som har noko å seie for straumliknande bruk. Bytekorienterte segment passar med bufferar, bitorienterte gjer det ikkje.
I praksis vel protokollen modusen, ikkje operatøren. Ein VPN-datakanal brukar konstruksjonen protokollen føreskriv, med si eiga integritetsvern, og ei biblioteksliste fortel berre kva namn som finst.
Å lese ei ukvalifisert CFB-etikett
Ei ukvalifisert CFB-etikett treng implementeringskonteksten sin. I OpenSSL 1.0.2-hovuda er EVP_aes_128_cfb ein makro for EVP_aes_128_cfb128, med samsvarande alias for 192 og 256-bits nøklar. Det er ein API-namnekonvensjon frå éin grein, ikkje ein påstand om at kvart bibliotek, filformat eller GUI utvidar forkortinga på same måte. Sjekk hovudet eller dokumentasjonen for versjonen framfor deg.
Om ein eldre profil seier CFB og motparten godtek det, vert dei forhandla parametrane registrerte ein stad: i ein logg, ein konfigurasjonsdump, eit API-svar. Les dei i staden for å utleie segmentstorleiken frå ein visingsstreng.
Kva eit modusnamn ikkje fortel deg
Namnet skildrar krypteringsatferd og ingenting anna. Ein VPN treng framleis integritetsvern, nøkkelutleiing og motpartsautentisering, og CFB leverer ingen av dei. Å byte CFB8 mot CFB1 er heller ikkje ei kosmetisk endring: atferda på tråden er annleis, og begge partar må støtte same konstruksjonen. Eit namn i eit bibliotek beviser heller ikkje at den utrulla gatewayen godtek det for datakanalen sin.
For alt som vert vedlikehalde, bruk protokollen sitt fullstendige vernsopplegg og operatøren sin policy, og registrer bibliotek- og gatewayversjonar, det nøyaktige alternativet og det forhandla resultatet. Det gamle namnet forklarar kva du les; det rettferdiggjer ikkje å gjenopplive konfigurasjonen.