CFB1 laban sa CFB8 laban sa CFB128: laki ng feedback ito, hindi laki ng key
Ang numero pagkatapos ng CFB ay hakbang ng feedback, hindi haba ng key: gumagamit ang CFB1, CFB8 at CFB128 ng 128-bit na bloke. Basahin ang lumang pangalan nang hindi kumakatha ng mahinang key.
Ang pangalang tulad ng AES-256-CFB1 ay may dalawang numero, at magkaibang tanong ang sinasagot nila. Ang 256 ay haba ng key ng AES. Ang 1 ay feedback ng CFB, o laki ng segment, isang katangian ng kung paano isinusulong ng mode ang sariling estado. Kapag binasa ang 1 bilang haba ng key, mukhang sakunang maling configuration ang pangalan, at iyon ang dahilan kung bakit paulit-ulit na bumabalik ang tanong.
Magpasya kung alin sa tatlong dami ang tinitignan mo bago husgahan ang pangalan: laki ng key, laki ng bloke o laki ng segment. Ang una lang ang parameter ng seguridad sa karaniwang kahulugan.
Tatlong numero, tatlong dami
Tumanggap ang AES ng 128, 192 o 256-bit na key at may 128-bit na bloke anuman ang piliin mo. Ang laki ng bloke ay pag-aari ng AES, hindi ng mode. Ang hulapi ng CFB ay ang ikatlong dami: gaano karaming datos ang ginagamit at ibinabalik ng mode kada hakbang. Ang dokumentasyon ng AES ng OpenSSL ay tahasang naglilista ng mga laki ng paglilipat na iyon para sa mga variant ng CFB.
Nagbabalik ang CFB1 ng isang bit kada pagkakataon, ang CFB8 ng isang byte, ang CFB128 ng buong bloke. Pareho ang ginagamit ng tatlo sa loob: ang 128-bit na block cipher; ang nagbabago ay kung ilang bit ng bawat kalkuladong bloke ang ginagamit kada operasyon. Kaya inililipat ng hulapi ang gastos at pag-uugali ng buffering, hindi ang lakas ng key.
| 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 |
Bakit hindi kailanman nagbabago ang laki ng bloke
Ang AES ay block cipher na may takdang 128-bit na bloke, at ang mga mode ay mga konstruksiyon na itinayo sa paligid nito. Wala sa kanila ang nagpapaliit ng bloke upang tumugma sa laki ng segment. Ang implementasyon ng CFB1 ay nagkalkula pa rin ng buong bloke ng AES at kumukuha ng isang bit ng resulta. Itinatapon ang ibang bit para sa hakbang na iyon, at doon mismo nakalagay ang gastos sa kahusayan.
Kaya ang isang-bit na feedback ay hindi nangangahulugang isang-bit na key, at hindi maaaring ihanay ang pangalan ayon sa hulapi nito. Ang CFB128 ay hindi apat na beses na mas matibay kaysa CFB32; mas malalaking segment ang pinoproseso nito.
Ano ang talagang binabago ng laki ng segment
Binabago ng laki ng segment kung gaano karaming ciphertext ang ibinabalik kada hakbang at gaano karaming plaintext ang kayang dalhin ng bawat hakbang. Binabago rin nito ang pagkalat ng error at pag-uugali ng buffering, na mahalaga sa paggamit na parang stream. Ang mga segment na nakatuon sa byte ay umayon sa buffer, ang nakatuon sa bit ay hindi.
Sa pagsasagawa, ang protocol ang pumipili ng mode, hindi ang operator. Ang channel ng datos ng VPN ay gumagamit ng konstruksiyong itinakda ng protocol nito, kasama ang sariling proteksiyon sa integridad, at ang listahan ng library ay nagsasabi lamang kung anong mga pangalan ang umiiral.
Pagbasa ng CFB label na walang kwalipikasyon
Ang CFB label na walang kwalipikasyon ay nangangailangan ng konteksto ng implementasyon nito. Sa mga header ng OpenSSL 1.0.2, ang EVP_aes_128_cfb ay macro para sa EVP_aes_128_cfb128, may tumutugmang alias para sa 192 at 256-bit na key. Iyon ay kumbensiyon sa pagpapangalan ng API mula sa isang branch, hindi pahayag na bawat library, format ng file o GUI ay nagpapalawak ng daglat sa parehong paraan. Suriin ang header o dokumentasyon ng bersiyong nasa harap mo.
Kung sinasabi ng lumang profile na CFB at tinatanggap ito ng kabilang dulo, naitala ang napagkasunduang parameter sa isang lugar: sa log, sa dump ng configuration, sa tugon ng API. Basahin ang mga iyon sa halip na hulaan ang laki ng segment mula sa string na ipinapakita.
Ano ang hindi sinasabi ng pangalan ng mode
Inilalarawan ng pangalan ang pag-uugali ng encryption at wala nang iba. Kailangan pa rin ng VPN ang proteksiyon sa integridad, derivasyon ng key at pagpapatotoo ng kabilang dulo, at wala ni isa sa mga iyon ang ibinibigay ng CFB. Hindi rin kosmetikong pagbabago ang pagpapalit ng CFB8 ng CFB1: iba ang pag-uugali sa kawad at dapat parehong suportahan ng dalawang panig ang parehong konstruksiyon. Ni hindi pinapatunayan ng pangalan sa library na tinatanggap ito ng naka-deploy na gateway para sa sariling channel ng datos.
Para sa anumang pinapanatili, gamitin ang buong kaayusan ng proteksiyon ng protocol at patakaran ng operator, at itala ang mga bersiyon ng library at gateway, ang eksaktong opsiyon at ang napagkasunduang resulta. Ipinapaliwanag ng lumang pangalan ang binabasa mo; hindi nito binibigyang-katwiran ang muling pagbuhay sa configuration.