AES-256 vs OFB: pilih konstruksi cipher VPN yang lengkap

AES-256 dan OFB menjawab pertanyaan yang berbeda, dan di sinilah tinjauan cipher keliru ketika keduanya diperlakukan sebagai opsi yang bersaing. Satu menyebut cipher blok dengan ukuran kunci; yang lain menjelaskan bagaimana cipher blok diubah menjadi aliran untuk pesan yang lebih panjang. Buku pedoman untuk memilih perlindungan harus melihat seluruh konstruksi, termasuk bagaimana penerima mendeteksi paket yang diubah.

Sebutkan empat bagian konstruksi

Setiap tinjauan bermuara pada empat pertanyaan: primitif dan ukuran kunci apa, bagaimana pesan diproses dengannya, bagaimana penerima menolak perubahan tanpa izin, dan bagaimana protokol mengelola masukan, kunci, serta masa hidupnya. Daftar nama yang familier hanya menjawab yang pertama. Yang kedua dan ketiga adalah tempat perbedaan nyata berada, dan yang keempat adalah tempat implementasi diam-diam berbeda. Tanyakan dalam urutan itu dan tuliskan jawabannya.

OFB muncul di antara mode kerahasiaan dalam publikasi NIST tentang mode cipher blok, dan kerahasiaan adalah semua yang ditawarkannya. Protokol yang memasangkan mode enkripsi dengan MAC terpisah harus menyusunnya dengan benar, dan nama algoritme tidak membuktikan susunan itu. Karena itu nama mode saja tidak bisa menyelesaikan keputusan penerapan.

Pertanyaan keempat adalah yang benar-benar bisa diverifikasi operator pada sistem yang berjalan.

Utamakan konstruksi yang terautentikasi

Enkripsi terautentikasi memberi kerahasiaan dan integritas sekaligus, dan konstruksi AEAD juga melindungi data terkait dari perubahan tanpa mengenkripsinya. Itu sifat perlindungan paket, dan tidak ada hubungannya dengan apakah seseorang berhasil masuk.

Panduan Panduan pengaturan kriptografi OpenVPN dari Netgate menunjuk opsi AEAD, termasuk AES-GCM, untuk kanal data, dan itulah jenis kebijakan yang didukung untuk diikuti. Gunakan pilihan yang didukung rilis terpasang dan klien peer, alih-alih menyalin peringkat mode historis ke penerapan baru. Kompatibilitas lama, backend kripto, dan dukungan offload semuanya membatasi apa yang benar-benar tersedia.

Konstruksi yang didukung mengalahkan susunan cerdik setiap kali.

Baca hasil yang dinegosiasikan, bukan tawarannya

Cipher yang muncul di daftar yang diterima tidak mengatakan apa pun tentang sesi saat ini. Baca perlindungan kanal data yang dinegosiasikan dari klien atau gateway, lalu bandingkan dengan kebijakan yang ingin Anda tegakkan. Konfigurasi yang masih mencantumkan opsi lama untuk satu peer lama adalah keputusan kompatibilitas, bukan pernyataan tentang sesi di depan Anda.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Di gateway, keluaran yang setara adalah asosiasi keamanan atau detail kripto koneksi, tergantung platform. Dalam kedua hal, tawaran dan hasil adalah fakta yang berbeda. Daftar yang memuat opsi lama untuk satu peer lama tidak berarti setiap sesi memakainya, dan sesi yang memakainya adalah hal yang perlu Anda ketahui.

Catat kedua fakta bersama, dengan tanggal dan versi klien.

Ukur hanya yang bisa dibandingkan

Throughput bergantung pada perangkat keras titik akhir, implementasi, akselerasi, ukuran paket, dan konfigurasi yang dipilih. Panjang kunci maupun kata OFB tidak memberi tahu Anda penerapan mana yang lebih cepat. Karena itu tolok ukur dari situs lain paling banter adalah petunjuk tentang perangkat keras milik orang lain. Angka Anda sendiri dimulai dari titik akhir Anda sendiri.

Untuk perbandingan yang diizinkan, jaga titik akhir, beban kerja, dan kebijakan yang diperlukan tetap konstan, dan catat perlindungan yang dinegosiasikan plus versi implementasi. Lalu nilai hasilnya dari apakah aplikasi selesai, berapa banyak yang hilang, dan apa yang dilakukan titik akhir, alih-alih menyimpulkan biaya kripto dari satu uji kecepatan. Angka yang dihasilkan dalam kondisi lain adalah cerita, bukan pengukuran.

Jika peer lama tidak dapat memenuhi kebijakan, itu keputusan kompatibilitas bagi pemiliknya.

Jauhkan integritas dari tawar-menawar

Mematikan pemeriksaan integritas atau menerima server yang tidak terverifikasi bukanlah optimasi kinerja dan bukan perbaikan kompatibilitas. Itu mengubah sifat keamanan yang menjadi alasan konstruksi dipilih. Hal yang sama berlaku untuk memperluas daftar cipher yang diterima sampai peer lama terhubung: koneksi berhasil dan kebijakannya tidak ada lagi.

Tuliskan konstruksi yang diterima dan pemiliknya di buku pedoman, agar perubahan berikutnya dimulai dari keputusan, bukan dari preferensi.

Yang Anda inginkan adalah kebijakan yang bisa ditegakkan kedua ujung. Berdebat bahwa satu nama adalah yang terkuat adalah percakapan lain, dan biasanya berakhir tanpa keputusan.