Kekurangan AES-CTR?
Di atas kertas, kedengarannya * sangat * bagus untuk saya:
- aman
- cepat (dalam pengujian saya, ini agak lebih lambat daripada ECB (tetapi tanpa sebagian besar kelemahan, lebih dari itu di bawah) tetapi lebih cepat daripada setiap alternatif lain yang saya uji, yang
ECB, CTR, CBC, OFB, CFBditulis dalam urutan kinerja ( tautan ke kode patokan )) - mudah dimengerti
- tidak memerlukan padding (yang menurut saya secara signifikan mengurangi kemungkinan penerapan padding dengan cara yang tidak aman)
- mendukung paralelisasi (untuk enkripsi dan dekripsi)
- mendukung akses acak
.. satu-satunya kelemahan yang dapat saya pikirkan, adalah karena tidak memerlukan padding, implementasi dalam praktiknya mungkin akan mengungkapkan panjang pesan yang tepat , dibandingkan dengan mengungkapkan panjang pesan yang melingkar (misalnya skema berlapis dapat mengungkapkan sesuatu seperti the message is within 15 bytes of this length, sementara non Skema berlapis dapat muncul the message is *exactly* this long), dan jika itu menjadi perhatian, tidak seperti itu tidak dapat dikurangi dengan hanya menambahkan bantalan.
Kurasa aku melewatkan sesuatu, jadi ...
Apa kerugiannya?
Jawaban
Kekurangan:
Panjang pesan: Dalam Kriptografi, biasanya panjang pesan tidak dianggap rahasia. Ada pendekatan yang Anda dapat menambahkan nilai acak ke akhir atau awal atau keduanya jika ini benar-benar kebocoran informasi untuk Anda. Pendekatan acak bergantung pada kasus data Anda yang sebenarnya. Mungkin juga bahwa ukuran tetap yang ditentukan sebelumnya dapat digunakan karena email dapat dibatasi hingga 512 karakter. Pada akhirnya, setidaknya batas atas terungkap dalam semua kasus.
Penggunaan kembali pasangan (IV, kunci) adalah masalah nyata yang dapat menghilangkan kerahasiaan dengan teknik boks-menyeret. Ini tidak mengungkapkan kunci enkripsi.
Kurangnya otentikasi Seperti semua mode enkripsi yang tidak diautentikasi, mode CTR kosong tidak memiliki integritas dan otentikasi. Sedikit pembalikan dapat menyebabkan bencana akibat kelenturan mode CTR.
The AES-GCM modus yang menggunakan modus CTR operasi menyediakan semua-dalam-sekali, namun, ia memiliki yang sama (IV, kunci) masalah pasangan reuse. Ada mode Synthetic Initialization Vector (SIV) sebagai resistansi tanpa penyalahgunaan ( kertas , rfc8452 ) yang menghilangkan ini. Mode SIV masih dapat membocorkan bahwa pesan yang sama dikirim dengan kunci yang sama, sehingga pengamat dapat membedakannya.
Distinguisher pesan panjang: Mode CTR dirancang dengan Pseudo-Random-Function (PRF). Saat menggunakan AES dalam mode CTR, kami menggunakannya dengan Pseudo Random Permutation (PRP);$$E_k\colon \{0,1\}^n \to \{0,1\}^n.$$ Sedikit pun PRP selama blok pesan tidak mengulangi urutannya $E_k(0), E_k(1), \dots, E_k(\ell - 1)$ dengan $\ell < 2^n$tidak diulang. Jika pesan dengan panjang$\ell$-block tidak memiliki blok berulang, ini tidak masalah. Jika kita mendekati pesan sebagai blok acak seragam maka kita mengharapkan tabrakan$\ell \approx \sqrt{2^n} = 2^{n/2}$ oleh paradoks / serangan ulang tahun.
Jika digunakan dengan AES-128 untuk pesan panjang, periksa pengulangan. Pengulangan memungkinkan penyerang untuk membedakan ini dari acak seragam dengan probabilitas yang tidak dapat diabaikan .
Singkatnya, duplikat ciphertext di setiap posisi bocor bahwa pesannya berbeda.
Ukuran pesan per kunci: meskipun NIST mengatakan 64 nonce dan 64 bit counter, seseorang harus berhenti menggunakan kunci sebelumnya$2^{64}$blok. Ini karena menggunakan PRP (AES) daripada PRF dalam mode CTR .
Keunggulan lainnya:
Tidak perlu dekripsi: mode CTR tidak memerlukan dekripsi dari block cipher, ia selalu menggunakannya untuk enkripsi. Ini sangat membantu dalam lingkungan kendala. Menyederhanakan kode perangkat lunak dan perangkat keras juga.
Tidak perlu PRP: Tidak membutuhkan block cipher (PRP) sama sekali. Sebuah fungsi hash dapat digunakan seperti dalam seri ChaCha.
Prepocessing: aliran utama yang dihasilkan oleh mode CTR dapat disiapkan sebelumnya. Ini dapat membantu menggunakan buffer.
Mode CTR memiliki keamanan CPA .
Sedikit sejarah CTR
Mode CTR diperkenalkan oleh Whitfield Diffie dan Martin Hellman pada 1979
Privasi dan Otentikasi: Pengantar Kriptografi sebagai makalah diundang pada Prosiding IEEE, 67 (1979), hlm. 397–427.
Keamanan konkret dari Perlakuan Enkripsi Simetris, Bellare et. al, 97 memberikan batasan keamanan.
Lihat juga; Komentar untuk NIST tentang Mode Operasi AES: Enkripsi Mode CTR , oleh Lipmaa et al. untuk mengetahui detail keuntungan dan kerugian lainnya.
Schneier dan Ferguson awalnya merekomendasikan mode CTR, tetapi beralih ke mode CBC karena potensi kesulitan dalam memastikan bahwa penghitung tidak pernah digunakan kembali dengan kunci.
Meskipun pertanyaan Anda tampaknya berfokus pada sisi CTR dari suatu hal, ada baiknya Anda juga mendapatkan jawaban untuk membahas sisi AES. Ada setidaknya dua situasi di mana cipher blok lainnya mungkin lebih tepat.
Komputasi Aman :
Ada dua "kesulitan" utama AES sehubungan dengan komputasi yang aman (artinya komputasi multi-pihak dan NIZK terutama, tetapi juga kemungkinan enkripsi homomorfik penuh).
AES dihitung pada bidang karakteristik 2. Jika sistem MPC / FHE menggunakan karakteristik $p$ aritmatika, memiliki sandi dalam karakteristik 2 memerlukan konversi antara representasi yang berbeda (katakanlah, dari sebuah elemen dalam $\mathbb{Z}/p\mathbb{Z}$, atau dekomposisi basis 2 dari elemen semacam itu) yang lebih mahal daripada dalam perhitungan standar.
Secara umum, perkalian jauh lebih mahal (relatif) daripada penambahan dalam konteks penghitungan yang aman. Ini berarti bahwa seseorang dapat memiliki "model biaya" yang berbeda untuk membuat cipher, di mana seseorang lebih tertarik untuk mengurangi jumlah perkalian dalam cipher secara umum.
Sebuah cipher untuk melihat topik ini adalah MiMC (meskipun baru-baru ini ada serangan parsial terhadap cipher ini di "$\mathbb{F}_{2^k}$ versi "itu. Ia juga memiliki"$\mathbb{F}_p$versi, yang tidak terkena serangan).
Sistem Tertanam :
Pada mesin standar, implementasi perangkat keras AES (melalui instruksi AES-NI) memberikan kecepatan ~ 40x lebih cepat dari implementasi perangkat lunak AES yang dioptimalkan. Hal ini mempersulit persaingan dengan AES saat membandingkan AES-NI dengan implementasi perangkat lunak cipher lain. Tetapi jika Anda tidak memiliki AES-NI, cipher lain bisa menjadi lebih kompetitif. Posting oleh Matthew Green ini membahas penggunaan alternatif untuk AES (rekomendasinya saat menulis ini ~ 8 tahun yang lalu tidak melakukan ini, sebagai catatan) membahas sandi tertentu seperti Salsa20 yang menawarkan kecepatan 2x - 3x lebih cepat dari AES dalam perangkat lunak. Perhatikan bahwa Salsa20 secara teknis adalah stream cipher dibandingkan dengan AES sebagai block cipher, tetapi ini hanya untuk memotivasi agar dapat "mengalahkan" AES dengan kecepatan saat Anda tidak memiliki akses ke AES-NI.
Sumber yang lebih baik untuk cipher yang lebih cepat dalam lingkungan komputasi terbatas adalah Standardisasi Kriptografi Ringan NIST yang sedang berlangsung . Saya belum mengikuti ini dengan cermat, tetapi saat ini ada banyak minat penelitian dalam menemukan sandi baru untuk distandarisasi untuk (pada dasarnya) digunakan dalam sistem tertanam. Mereka saat ini berencana untuk memposting finalis putaran ke-3 mereka pada bulan Desember mendatang, jadi tidak mengherankan jika dalam beberapa tahun ke depan ada "cipher baru" yang menggantikan penggunaan AES di embedded system.
CTR memang mode operasi block cipher yang sangat bagus. Kelemahan utamanya adalah:
- itu tidak melindungi integritas pesan (dan pada kenyataannya memungkinkan penyerang untuk dengan mudah membalik bit arbitrer dalam pesan terenkripsi tanpa harus mendekripsinya), dan
- itu dapat membocorkan teks biasa jika blok penghitung pernah digunakan kembali; khususnya, enkripsi mode CTR memerlukan input nonce unik yang sama sekali tidak boleh digunakan kembali untuk dua pesan berbeda yang dienkripsi dengan kunci yang sama.
Untungnya, kedua masalah ini dapat diselesaikan dengan menggunakan mode CTR sebagai komponen dalam konstruksi tingkat yang lebih tinggi:
- Masalah pertama dapat diselesaikan dengan menggunakan mode enkripsi terotentikasi , banyak di antaranya (seperti EAX dan GCM ) didasarkan pada kombinasi mode CTR dengan kode otentikasi pesan .
- Masalah kedua dapat diselesaikan dengan menggunakan mode enkripsi "nonce misuse resistant" yang memperoleh nilai penghitung awal berdasarkan (antara lain) pesan teks biasa yang dienkripsi. Mode tersebut mencakup SIV dan GCM-SIV , keduanya juga didasarkan pada mode CTR dan juga menyediakan otentikasi pesan seperti yang dijelaskan di atas.
Tentu saja, penambahan otentikasi pesan memerlukan beberapa pemrosesan tambahan yang membuat mode ini lebih lambat daripada CTR mentah (meskipun implementasi GCM yang baik masih bisa sangat cepat). Secara khusus, untuk mendapatkan jaminan keamanan penuh dari mode ini, penerima harus mengautentikasi seluruh pesan sebelum meneruskan teks biasa yang didekripsi. Untuk mode tahan penyalahgunaan, hal yang sama juga berlaku saat mengenkripsi, karena seluruh pesan harus diproses untuk mendapatkan nilai penghitung awal sebelum dapat dienkripsi.
Namun, itu umumnya harga kecil yang harus dibayar untuk meningkatkan keamanan. Jika Anda dapat menggunakan mode tahan penyalahgunaan nonce seperti SIV atau GCM-SIV, saya sangat menyarankan Anda untuk melakukannya. Jika tidak, setidaknya gunakan mode AE berbasis nonce seperti GCM.