Mengapa Kunci Blowfish yang Lebih Panjang Tidak Memperbaiki Blok 64 Bit

Sebuah profil VPN menawarkan Blowfish dengan kunci 448 bit, dan seseorang mengusulkan menggunakan kunci terpanjang untuk mempertahankan cipher. Panjang kunci itu nyata, tetapi itu angka yang salah untuk dioptimalkan. Blowfish mengubah blok 64 bit tidak peduli seberapa panjang kuncinya, dan lebar blok adalah yang membatasi berapa banyak lalu lintas yang dapat dilindungi dengan aman oleh satu kunci. Jalankan pemeriksaan di bawah ini secara berurutan dan berhenti pada yang pertama yang membersihkan layanan, karena langkah berikutnya tidak dapat memperbaiki langkah sebelumnya.

Periksa apa yang sebenarnya dinegosiasikan para peer

Baca cipher kanal data dari kedua ujung, bukan dari profil yang ingin Anda terapkan. Konfigurasi klien dapat mencantumkan beberapa cipher, dan yang dipilih adalah hasil negosiasi antara dua implementasi dan versinya. Naikkan verbositas log pada koneksi uji dan baca baris kanal data, yang menyebutkan cipher dan ukuran kunci yang benar-benar diinisialisasi.

Jika cipher yang dinegosiasikan adalah AES-GCM atau ChaCha20-Poly1305, berhenti di sini. Konstruksi tersebut menggunakan blok 128 bit dan mengautentikasi muatan, sehingga argumen tabrakan 64 bit di bawah ini tidak berlaku bagi keduanya.

Pisahkan panjang kunci dari lebar blok

Blowfish menerima kunci dari 32 hingga 448 bit, dan dokumentasi penulis algoritme mencatat kedua angka secara terpisah. Kunci adalah rahasianya; blok adalah unit transformasi. Membuat rahasia lebih panjang mempersulit penebakan dan tidak melakukan apa pun terhadap lebar blok yang diproses cipher.

Dalam mode CBC, cipher diterapkan pada blok dengan lebar tetap, dirantai dengan blok ciphertext sebelumnya dan diisi padding di akhir. Untuk Blowfish lebar itu adalah 64 bit, atau delapan byte. Jadwal kunci bisa sebesar yang Anda inginkan; rantai tetap bergerak delapan byte setiap kali.

Itulah sebabnya menaikkan panjang kunci bukan mitigasi. Ini menangani brute force terhadap kunci, sementara risiko tabrakan di bawah adalah properti dari lebar blok dan mode.

Terapkan aritmetika ulang tahun pada ukuran blok

Blok 64 bit memiliki skala ulang tahun sekitar 2^32 blok yang dienkripsi di bawah satu kunci sebelum tabrakan menjadi mungkin. Setiap blok membawa delapan byte, jadi skala yang sama adalah sekitar 2^35 byte, atau 32 GiB data di bawah satu kunci.

Perlakukan itu sebagai skala, bukan kuota. Tabrakan bersifat probabilistik, dan apakah salah satunya membocorkan sesuatu bergantung pada mode, pola lalu lintas, dan apakah penyerang dapat mengenali atau memengaruhi plaintext di sekitarnya. Byte pertama setelah 32 GiB bukan peristiwa dekripsi, dan 32 GiB pertama tidak disertifikasi aman.

Para peneliti Sweet32 mendemonstrasikan pada 2016 serangan praktis terhadap cipher blok 64 bit, termasuk skenario OpenVPN, dalam kondisi yang memerlukan pengamatan dan pembangkitan lalu lintas. Default dan versi perangkat lunak yang mereka publikasikan adalah konteks historis, bukan deskripsi penerapan Anda.

Putuskan apakah penggunaan ulang CBC penting di sini

Dalam CBC, blok ciphertext yang berulang berarti dua blok plaintext berbeda dengan hubungan yang diketahui, karena XOR perantaian saling meniadakan. Penyerang yang dapat mengamati ciphertext dan mengetahui atau dapat memengaruhi salah satu plaintext dapat memulihkan informasi tentang yang lain. Kunci Blowfish tidak pernah diperlukan untuk itu.

Jadi pertanyaan yang relevan adalah berapa lama kunci tetap digunakan, berapa banyak lalu lintas yang lewat di bawahnya, dan apakah ada yang dapat mengamati dan mengarahkan lalu lintas itu. Rotasi kunci menurunkan jumlah blok per kunci, tetapi interval waktu bukan batas byte: terowongan yang sibuk dapat memindahkan jauh lebih banyak data daripada yang menganggur dalam jam yang sama. Jika Anda mempertahankan cipher lama, turunkan batasnya dari konstruksi dan volume aktual, bukan dari angka bulat.

Jika volume terukur per kunci tetap jauh di bawah skala ulang tahun, paparannya lebih kecil. Tetap saja bukan nol dan tetap menjadi alasan untuk merencanakan migrasi alih-alih berhenti khawatir.

Ganti ciphernya, bukan kuncinya

Pindahkan layanan ke cipher AEAD yang didukung dan pastikan kedua peer, versinya, dan backend kriptografinya dapat menegosiasikannya. Kunci Blowfish yang lebih panjang tidak mengubah apa pun yang penting, dan menebak direktif baru pada satu klien adalah cara terowongan yang berfungsi menjadi rusak. Uji perubahan pada satu klien dan satu server sebelum menyentuh sisa armada. Simpan profil lama tersedia untuk rollback sampai cipher baru melewati siklus koneksi penuh.

Pertahankan verifikasi sertifikat dan autentikasi akun selama perubahan. Keduanya menjawab pertanyaan berbeda: login yang berhasil tidak dapat memperlebar blok, dan cipher data yang lebih baik tidak menjadi alasan untuk memercayai server yang salah.

Tutup pemeriksaan dengan membaca cipher yang dinegosiasikan lagi pada koneksi baru, lalu pastikan cipher lama tidak lagi diterima. Jika peer masih menawarkannya, migrasi belum selesai, apa pun yang dikatakan profil di sisi lain.