Bakit Hindi Kayang Ayusin ng Mas Mahabang Blowfish Key ang 64-Bit na Block

Naghahain ang isang VPN profile ng Blowfish na may 448-bit na key, at may nagmumungkahi na gamitin ang pinakamahabang key upang mapanatili ang cipher. Totoo ang haba ng key, ngunit ito ang maling bilang na i-optimize. Binabago ng Blowfish ang 64-bit na block gaano man kahaba ang key, at ang lapad ng block ang naglilimita kung gaano karaming trapiko ang kayang protektahan ng isang key nang ligtas. Patakbuhin ang mga pagsusuri sa ibaba nang sunod-sunod at huminto sa unang naglilinis ng serbisyo, dahil hindi kayang ayusin ng susunod na hakbang ang nauna.

Suriin kung ano talaga ang napagkasunduan ng mga peer

Basahin ang cipher ng data channel mula sa magkabilang dulo, hindi mula sa profile na balak mong i-deploy. Maaaring maglista ang configuration ng client ng ilang cipher, at ang napili ay resulta ng negosasyon sa pagitan ng dalawang implementasyon at ng kanilang mga bersyon. Taasan ang verbosity ng log sa isang test connection at basahin ang linya ng data channel, na nagsasaad ng cipher at laki ng key na aktuwal na na-initialize.

Kung ang napagkasunduang cipher ay AES-GCM o ChaCha20-Poly1305, huminto dito. Gumagamit ang mga konstruksiyong iyon ng 128-bit na block at nagpapatunay ng payload, kaya hindi sila saklaw ng argumento tungkol sa 64-bit na banggaan sa ibaba.

Ihiwalay ang haba ng key sa lapad ng block

Tumatanggap ang Blowfish ng mga key mula 32 hanggang 448 bit, at idinodokumento ng may-akda ng algorithm ang dalawang bilang nang hiwalay. Ang key ay ang sikreto; ang block ay ang yunit ng transpormasyon. Ang mas mahabang sikreto ay nagpapahirap sa paghula at wala itong ginagawa sa lapad ng block na pinoproseso ng cipher.

Sa CBC mode, inilalapat ang cipher sa mga block na may fixed na lapad, nakakadena sa naunang ciphertext block at may padding sa dulo. Para sa Blowfish, ang lapad na iyon ay 64 bit, o walong byte. Maaaring kasinglaki ng gusto mo ang key schedule; umuusad pa rin ang chain ng walong byte bawat pagkakataon.

Kaya't ang mas mahabang key ay hindi mitigation. Tinutugunan nito ang brute force laban sa key, samantalang ang panganib ng banggaan sa ibaba ay katangian ng lapad ng block at ng mode.

Ilapat ang birthday arithmetic sa laki ng block

Ang 64-bit na block ay may birthday scale na humigit-kumulang 2^32 block na naka-encrypt sa ilalim ng isang key bago maging malamang ang mga banggaan. Nagdadala ang bawat block ng walong byte, kaya ang parehong scale ay humigit-kumulang 2^35 byte, o 32 GiB ng data sa ilalim ng isang key.

Ituring itong sukat, hindi quota. Probabilistiko ang mga banggaan, at kung may mabubunyag ang isa ay nakadepende sa mode, sa pattern ng trapiko at sa kung makikilala o maiimpluwensiyahan ng attacker ang nakapaligid na plaintext. Ang unang byte pagkalampas ng 32 GiB ay hindi kaganapan ng decryption, at ang unang 32 GiB ay hindi sertipikadong ligtas.

Ipinakita ng mga mananaliksik ng Sweet32 noong 2016 ang mga praktikal na pag-atake sa 64-bit na block cipher, kasama ang isang senaryo ng OpenVPN, sa mga kondisyong nangangailangan ng obserbasyon at pagbuo ng trapiko. Ang kanilang mga nailathalang default at bersyon ng software ay makasaysayang konteksto, hindi paglalarawan ng iyong deployment.

Magpasya kung mahalaga dito ang muling paggamit ng CBC

Sa CBC, ang paulit-ulit na ciphertext block ay nangangahulugang ang dalawang plaintext block ay nagkakaiba sa isang kilalang relasyon, dahil nagkakansela ang chaining XOR. Ang attacker na makakapag-obserba ng ciphertext at nakakaalam o makakaimpluwensiya sa isa sa mga plaintext ay maaaring makabawi ng impormasyon tungkol sa isa pa. Hindi kailanman kailangan ang Blowfish key para doon.

Kaya't ang mga kaugnay na tanong ay kung gaano katagal nananatili sa serbisyo ang isang key, gaano karaming trapiko ang dumadaan sa ilalim nito at kung may makakapag-obserba at makakapagpatnubay sa trapikong iyon. Binababa ng key renewal ang bilang ng block bawat key, ngunit ang agwat ng oras ay hindi limitasyon sa byte: ang abalang tunnel ay makakapaglipat ng mas maraming data kaysa sa walang ginagawa sa parehong oras. Kung pinapanatili mo ang isang lumang cipher, kunin ang limitasyon mula sa konstruksiyon at sa aktuwal na dami, hindi mula sa isang bilog na bilang.

Kung ang sinusukat na dami bawat key ay nananatiling malayo sa ilalim ng birthday scale, mas maliit ang exposure. Hindi pa rin ito sero at dahilan pa rin ito upang magplano ng migration sa halip na tumigil sa pag-aalala.

Palitan ang cipher, hindi ang key

Ilipat ang serbisyo sa isang sinusuportahang AEAD cipher at kumpirmahin na kayang pagkasunduan ito ng dalawang peer, ng kanilang mga bersyon at ng kanilang cryptographic backend. Walang binabago ang mas mahabang Blowfish key na mahalaga, at ang paghula ng bagong direktiba sa isang client ay paraan ng pagkasira ng gumaganang tunnel. Subukan ang pagbabago sa isang client at isang server bago hawakan ang natitirang fleet. Panatilihing available ang lumang profile para sa rollback hanggang makapasa ang bagong cipher sa isang buong connection cycle.

Panatilihin ang certificate verification at account authentication habang nagbabago. Sumasagot sila sa magkaibang tanong: hindi kayang palawakin ng matagumpay na login ang isang block, at hindi nagbibigay-katwiran ang mas magandang data cipher upang magtiwala sa maling server.

Isara ang pagsusuri sa pamamagitan ng muling pagbasa ng napagkasunduang cipher sa isang bagong connection at pagkatapos ay kumpirmahin na hindi na tinatanggap ang lumang cipher. Kung inaalok pa rin ito ng isang peer, hindi pa tapos ang migration, anuman ang sabihin ng profile sa kabilang panig.