Manakah dari mereka yang lebih disukai dalam situasi apa?

Saya ingin melihat daftar evaluasi crtieria untuk berbagai mode, dan mungkin diskusi tentang penerapan setiap kriteria.

Sebagai contoh, saya pikir salah satu kriteria adalah "ukuran kode" untuk enkripsi dan dekripsi, yang penting untuk sistem tertanam kode-mikro, seperti adapter jaringan 802.11. JIKA kode yang diperlukan untuk mengimplementasikan CBC jauh lebih kecil daripada yang diperlukan untuk CTR (saya tidak tahu ini benar, itu hanya sebuah contoh), maka saya bisa mengerti mengapa mode dengan kode yang lebih kecil lebih disukai. Tetapi jika saya menulis aplikasi yang berjalan di server, dan perpustakaan AES saya menggunakan mengimplementasikan CBC dan CTR, maka kriteria ini tidak relevan.

Lihat apa yang saya maksud dengan "daftar kriteria evaluasi dan penerapan setiap kriteria" ??

Ini tidak benar-benar terkait pemrograman tetapi terkait algoritma.

• ECB tidak boleh digunakan jika mengenkripsi lebih dari satu blok data dengan kunci yang sama.

• CBC, OFB dan CFB serupa, namun OFB / CFB lebih baik karena Anda hanya perlu enkripsi dan bukan dekripsi, yang dapat menghemat ruang kode.

• CTR digunakan jika Anda ingin paralelisasi yang baik (mis. Kecepatan), bukan CBC / OFB / CFB.

• Mode XTS adalah yang paling umum jika Anda menyandikan data yang dapat diakses secara acak (seperti hard disk atau RAM).

• OCB sejauh ini merupakan mode terbaik, karena memungkinkan enkripsi dan otentikasi dalam sekali jalan. Namun ada paten di Amerika Serikat.

Satu-satunya hal yang harus Anda ketahui adalah bahwa ECB tidak akan digunakan kecuali jika Anda hanya mengenkripsi 1 blok. XTS harus digunakan jika Anda mengenkripsi data yang diakses secara acak dan bukan stream.

• Anda harus SELALU menggunakan IV unik setiap kali Anda mengenkripsi, dan mereka harus acak . Jika Anda tidak dapat menjamin mereka acak , gunakan OCB karena hanya membutuhkan nonce , bukan IV , dan ada perbedaan yang berbeda. Sebuah Nonce tidak drop keamanan jika orang bisa menebak yang berikutnya, seorang IV dapat menyebabkan masalah ini.

Harap pertimbangkan lama dan sulit jika Anda tidak dapat menerapkan kriptografi Anda sendiri

Kebenaran jelek dari masalah ini adalah bahwa jika Anda mengajukan pertanyaan ini, Anda mungkin tidak akan dapat merancang dan mengimplementasikan sistem yang aman.

Biarkan saya mengilustrasikan poin saya: Bayangkan Anda sedang membangun aplikasi web dan Anda perlu menyimpan beberapa data sesi. Anda bisa menetapkan setiap pengguna ID sesi dan menyimpan data sesi di server dalam ID sesi pemetaan peta hash ke data sesi. Tetapi kemudian Anda harus berurusan dengan keadaan sial ini di server dan jika pada titik tertentu Anda membutuhkan lebih dari satu server hal-hal akan menjadi berantakan. Jadi alih-alih Anda memiliki ide untuk menyimpan data sesi dalam cookie di sisi klien. Anda akan mengenkripsi itu tentu saja sehingga pengguna tidak dapat membaca dan memanipulasi data. Jadi mode apa yang harus Anda gunakan? Datang ke sini Anda membaca jawaban teratas (maaf karena memilih Anda keluar dari myforwik). Yang pertama tertutup - ECB - bukan untuk Anda, Anda ingin mengenkripsi lebih dari satu blok, yang berikutnya - CBC - terdengar bagus dan Anda tidak memerlukan paralelisme CTR, Anda tidak perlu akses acak, jadi tidak ada XTS dan paten adalah PITA, jadi tidak ada OCB. Menggunakan pustaka crypto Anda, Anda menyadari bahwa Anda memerlukan beberapa padding karena Anda hanya dapat mengenkripsi kelipatan ukuran blok. Anda memilihPKCS7 karena didefinisikan dalam beberapa standar kriptografi serius. Setelah membaca bahwa CBC terbukti aman jika digunakan dengan IV acak dan cipher blok aman, Anda merasa tenang walaupun Anda menyimpan data sensitif Anda di sisi klien.

Bertahun-tahun kemudian setelah layanan Anda benar-benar tumbuh ke ukuran yang signifikan, seorang spesialis keamanan TI menghubungi Anda dalam pengungkapan yang bertanggung jawab. Dia memberi tahu Anda bahwa dia dapat mendekripsi semua cookie Anda menggunakan serangan oracle padding , karena kode Anda menghasilkan halaman kesalahan jika paddingnya entah bagaimana rusak.

Ini bukan skenario hipotetis: Microsoft memiliki kekurangan ini di ASP.NET sampai beberapa tahun yang lalu.

Masalahnya adalah ada banyak jebakan tentang kriptografi dan sangat mudah untuk membangun sistem yang terlihat aman bagi orang awam tetapi sepele untuk istirahat bagi penyerang berpengetahuan.

Apa yang harus dilakukan jika Anda perlu mengenkripsi data

Untuk koneksi langsung, gunakan TLS (pastikan untuk memeriksa nama host sertifikat dan rantai penerbit). Jika Anda tidak dapat menggunakan TLS, cari API tingkat tertinggi yang ditawarkan sistem Anda untuk tugas Anda dan pastikan Anda memahami jaminan yang ditawarkannya dan yang lebih penting apa yang tidak dijaminnya. Untuk contoh di atas kerangka kerja seperti Play menawarkan fasilitas penyimpanan sisi klien , itu tidak membatalkan data yang disimpan setelah beberapa waktu, dan jika Anda mengubah keadaan sisi klien, penyerang dapat mengembalikan keadaan sebelumnya tanpa Anda sadari.

Jika tidak ada abstraksi tingkat tinggi yang tersedia gunakan pustaka crypto tingkat tinggi. Contoh yang menonjol adalah NaCl dan implementasi portabel dengan banyak ikatan bahasa adalah Sodium . Menggunakan perpustakaan seperti itu Anda tidak perlu peduli dengan mode enkripsi dll. Tetapi Anda harus lebih berhati-hati tentang detail penggunaan daripada dengan abstraksi tingkat yang lebih tinggi, seperti tidak pernah menggunakan nonce dua kali.

Jika karena alasan tertentu Anda tidak dapat menggunakan pustaka crypto tingkat tinggi, misalnya karena Anda perlu berinteraksi dengan sistem yang ada dengan cara tertentu, tidak ada cara untuk mendidik diri sendiri secara menyeluruh. Saya merekomendasikan membaca Teknik Kriptografi oleh Ferguson, Kohno dan Schneier . Tolong jangan membodohi diri sendiri dengan percaya bahwa Anda dapat membangun sistem yang aman tanpa latar belakang yang diperlukan. Kriptografi sangat halus dan hampir tidak mungkin untuk menguji keamanan suatu sistem.

Perbandingan mode

Hanya enkripsi:

• Mode yang memerlukan bantalan : Seperti pada contoh, bantalan biasanya dapat berbahaya karena membuka kemungkinan serangan bantalan oracle. Pertahanan termudah adalah untuk mengotentikasi setiap pesan sebelum dekripsi. Lihat di bawah.
  • ECB mengenkripsi setiap blok data secara independen dan blok plaintext yang sama akan menghasilkan blok ciphertext yang sama. Lihatlah gambar Tux terenkripsi ECB pada halaman Wikipedia ECB untuk melihat mengapa ini merupakan masalah serius. Saya tidak tahu ada kasus penggunaan di mana ECB akan diterima.
  • CBC memiliki IV dan dengan demikian membutuhkan keacakan setiap kali pesan dienkripsi, mengubah bagian dari pesan memerlukan enkripsi ulang semuanya setelah perubahan, kesalahan transmisi dalam satu blok ciphertext benar-benar menghancurkan plaintext dan mengubah dekripsi blok berikutnya, dekripsi bisa diparalelkan / enkripsi tidak bisa, plaintext bisa ditempa sampai tingkat tertentu - ini bisa menjadi masalah .
• Mode stream cipher : Mode ini menghasilkan aliran data pseudo acak yang mungkin atau mungkin tidak bergantung pada teks biasa. Demikian pula untuk melakukan streaming cipher secara umum, pseudo random stream yang dihasilkan adalah XOR dengan plaintext untuk menghasilkan ciphertext. Karena Anda dapat menggunakan bit acak dari aliran acak sesuka Anda, Anda tidak perlu melapisi sama sekali. Kerugian dari kesederhanaan ini adalah enkripsi sepenuhnya dapat ditempa, yang berarti bahwa dekripsi dapat diubah oleh penyerang dengan cara apa pun yang disukainya seperti untuk plaintext p1, ciphertext c1 dan aliran acak pseudo r dan penyerang dapat memilih perbedaan d sehingga dekripsi ciphertext c2 = c1⊕d adalah p2 = p1⊕d, karena p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Juga aliran acak semu yang sama tidak boleh digunakan dua kali karena untuk dua ciphertext c1 = p1⊕r dan c2 = p2⊕r, seorang penyerang dapat menghitung xor dari dua plaintext sebagai c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Itu juga berarti bahwa mengubah pesan memerlukan enkripsi ulang yang lengkap, jika pesan asli bisa diperoleh oleh penyerang. Semua mode sandi uap ini hanya membutuhkan operasi enkripsi sandi sandi, jadi tergantung pada sandi ini mungkin menghemat ruang (silikon atau kode mesin) di lingkungan yang sangat terbatas.
  • CTR sederhana, ia menciptakan aliran acak semu yang tidak tergantung pada teks biasa, aliran acak semu yang berbeda diperoleh dengan menghitung dari berbagai nonces / IVs yang dikalikan dengan panjang pesan maksimum sehingga tumpang tindih dicegah, menggunakan enkripsi pesan nonces adalah mungkin tanpa per pesan, keacakan, dekripsi, dan enkripsi diselesaikan secara paralel, kesalahan transmisi hanya mempengaruhi bit yang salah dan tidak lebih
  • OFB juga menciptakan aliran acak pseudo yang independen dari plaintext, aliran acak semu yang berbeda diperoleh dengan memulai dengan nonce atau IV acak yang berbeda untuk setiap pesan, baik enkripsi maupun dekripsi dapat diparalelkan, karena dengan RKT yang menggunakan enkripsi pesan nonces dimungkinkan tanpa per pesan keacakan, seperti dengan kesalahan transmisi CTR hanya mempengaruhi bit yang salah dan tidak lebih
  • Aliran acak semu CFB bergantung pada plaintext, diperlukan perbedaan nonce atau IV acak untuk setiap pesan, seperti dengan CTR dan OFB menggunakan enkripsi pesan nonces dimungkinkan tanpa per pesan keacakan, dekripsi diparalelkan / enkripsi tidak, kesalahan transmisi sepenuhnya hancurkan blok berikut, tetapi hanya efek bit yang salah di blok saat ini
• Mode enkripsi disk : Mode ini khusus untuk mengenkripsi data di bawah abstraksi sistem file. Untuk alasan efisiensi mengubah beberapa data pada disk hanya harus meminta penulisan ulang paling banyak satu blok disk (512 byte atau 4kib). Mereka berada di luar cakupan jawaban ini karena mereka memiliki skenario penggunaan yang sangat berbeda dari yang lain. Jangan menggunakannya untuk apa pun kecuali enkripsi disk level blok . Beberapa anggota: XEX, XTS, LRW.

Enkripsi terotentikasi:

Untuk mencegah padding serangan oracle dan perubahan pada ciphertext, seseorang dapat menghitung kode otentikasi pesan (MAC) pada ciphertext dan hanya mendekripsi itu jika belum dirusak. Ini disebut mengenkripsi-lalu-mac dan harus lebih disukai daripada pesanan lain . Kecuali untuk kasus penggunaan sangat sedikit, keaslian sama pentingnya dengan kerahasiaan (yang terakhir adalah tujuan enkripsi). Skema enkripsi terotentikasi (dengan data terkait (AEAD)) menggabungkan proses enkripsi dan otentikasi dua bagian menjadi mode blok cipher yang juga menghasilkan tag otentikasi dalam proses tersebut. Dalam kebanyakan kasus ini menghasilkan peningkatan kecepatan.

• CCM adalah kombinasi sederhana dari mode CTR dan CBC-MAC. Menggunakan dua enkripsi blok cipher per blok sangat lambat.
• OCB lebih cepat tetapi terbebani oleh paten. Untuk perangkat lunak bebas (seperti dalam kebebasan) atau non-militer, pemegang paten telah memberikan lisensi gratis .
• GCM adalah kombinasi yang sangat cepat tetapi kompleks dari mode CTR dan GHASH, MAC atas bidang Galois dengan 2 ^ 128 elemen. Penggunaannya yang luas dalam standar jaringan penting seperti TLS 1.2 dicerminkan oleh instruksi khusus yang telah diperkenalkan Intel untuk mempercepat perhitungan GHASH.

Rekomendasi:

Mempertimbangkan pentingnya otentikasi, saya akan merekomendasikan dua mode cipher blok berikut untuk kebanyakan kasus penggunaan (kecuali untuk tujuan enkripsi disk): Jika data diautentikasi oleh tanda tangan asimetris gunakan CBC, jika tidak gunakan GCM.

Analisis formal telah dilakukan oleh Phil Rogaway pada 2011, di sini . Bagian 1.6 memberikan ringkasan yang saya transkripsikan di sini, menambahkan penekanan saya sendiri dalam huruf tebal (jika Anda tidak sabar, maka rekomendasinya adalah menggunakan mode CTR, tetapi saya menyarankan Anda membaca paragraf saya tentang integritas pesan versus enkripsi di bawah).

Perhatikan bahwa sebagian besar dari ini memerlukan IV untuk menjadi acak, yang berarti tidak dapat diprediksi dan karenanya harus dihasilkan dengan keamanan kriptografi. Namun, beberapa hanya memerlukan "nonce", yang tidak menuntut properti itu tetapi sebaliknya hanya mengharuskan itu tidak digunakan kembali. Oleh karena itu desain yang mengandalkan nonce lebih rentan kesalahan daripada desain yang tidak (dan percayalah, saya telah melihat banyak kasus di mana CBC tidak dilaksanakan dengan pemilihan IV yang tepat). Jadi, Anda akan melihat bahwa saya telah menambahkan dengan berani ketika Rogaway mengatakan sesuatu seperti "kerahasiaan tidak tercapai ketika IV adalah nonce", itu berarti bahwa jika Anda memilih IV Anda yang aman secara kriptografis (tidak dapat diprediksi), maka tidak ada masalah. Tetapi jika tidak, maka Anda kehilangan sifat keamanan yang baik. Jangan sekali-kali menggunakan kembali infus untuk mode-mode ini.

Juga, penting untuk memahami perbedaan antara integritas pesan dan enkripsi. Enkripsi menyembunyikan data, tetapi penyerang mungkin dapat memodifikasi data yang dienkripsi, dan hasilnya berpotensi diterima oleh perangkat lunak Anda jika Anda tidak memeriksa integritas pesan. Sementara pengembang akan mengatakan "tetapi data yang dimodifikasi akan kembali sebagai sampah setelah dekripsi", seorang insinyur keamanan yang baik akan menemukan kemungkinan bahwa sampah tersebut menyebabkan perilaku buruk dalam perangkat lunak, dan kemudian ia akan mengubah analisis itu menjadi serangan nyata. Saya telah melihat banyak kasus di mana enkripsi digunakan tetapi integritas pesan sangat dibutuhkan lebih dari enkripsi. Pahami apa yang Anda butuhkan.

Saya harus mengatakan bahwa meskipun GCM memiliki kedua enkripsi dan integritas pesan, itu adalah desain yang sangat rapuh: jika Anda menggunakan kembali IV, Anda kacau - penyerang dapat memulihkan kunci Anda. Desain lain kurang rapuh, jadi saya pribadi takut untuk merekomendasikan GCM berdasarkan jumlah kode enkripsi yang buruk yang saya lihat dalam praktiknya.

Jika Anda membutuhkan keduanya, integritas pesan dan enkripsi, Anda dapat menggabungkan dua algoritma: biasanya kita melihat CBC dengan HMAC, tetapi tidak ada alasan untuk mengikat diri Anda dengan CBC. Yang penting untuk diketahui adalah mengenkripsi terlebih dahulu, lalu MAC konten yang dienkripsi , bukan sebaliknya. Juga, IV harus menjadi bagian dari perhitungan MAC.

Saya tidak mengetahui masalah IP.

Sekarang untuk hal-hal baik dari Profesor Rogaway:

Memblokir mode sandi, enkripsi tetapi tidak integritas pesan

ECB : Blockcipher, mode mengenkripsi pesan yang merupakan kelipatan dari n bit dengan secara terpisah mengenkripsi setiap bagian n-bit. Properti keamanan lemah , metode bocor kesetaraan blok di kedua posisi blok dan waktu. Dari nilai warisan yang cukup besar, dan nilai sebagai blok bangunan untuk skema lain, tetapi moda tersebut tidak mencapai tujuan keamanan yang secara umum diinginkan dalam haknya sendiri dan harus digunakan dengan sangat hati-hati; ECB tidak boleh dianggap sebagai mode kerahasiaan "tujuan umum" .

CBC : Skema enkripsi berbasis IV, mode aman sebagai skema enkripsi probabilistik, mencapai indistinguishability dari bit acak, dengan asumsi IV acak. Kerahasiaan tidak akan tercapai jika IV hanya merupakan nonce , atau jika nonce dienkripsi dengan kunci yang sama yang digunakan oleh skema, seperti yang disarankan oleh standar secara salah. Ciphertext sangat mudah ditempa. Tidak ada keamanan serangan ciphertext (CCA) yang dipilih. Kerahasiaan tidak dapat diperoleh jika ada ramalan bantalan yang benar untuk banyak metode bantalan. Enkripsi tidak efisien karena secara inheren serial. Banyak digunakan, properti keamanan mode-privasi mode ini sering menyebabkan penyalahgunaan. Dapat digunakan sebagai blok bangunan untuk algoritma CBC-MAC. Saya tidak dapat mengidentifikasi kelebihan penting dibandingkan mode CTR.

CFB : Skema enkripsi berbasis IV, mode aman sebagai skema enkripsi probabilistik, mencapai ketidakterbandingan dari bit acak, dengan asumsi IV acak. Kerahasiaan tidak tercapai jika IV dapat diprediksi , atau jika dibuat oleh nonce yang dienkripsi dengan kunci yang sama dengan yang digunakan oleh skema, seperti yang disarankan oleh standar secara salah. Ciphertext bisa ditempa. Tidak ada keamanan CCA. Enkripsi tidak efisien karena secara inheren serial. Skema tergantung pada parameter s, 1 ≤ s ≤ n, biasanya s = 1 atau s = 8. Tidak efisien untuk memerlukan satu panggilan blockcipher untuk hanya memproses bit s. Mode ini mencapai properti "sinkronisasi diri" yang menarik; penyisipan atau penghapusan sejumlah karakter s-bit ke dalam ciphertext hanya sementara mengganggu dekripsi yang benar.

OFB : Skema enkripsi berbasis IV, mode aman sebagai skema enkripsi probabilistik, mencapai indistinguishability dari bit acak, dengan asumsi IV acak. Kerahasiaan tidak tercapai jika IV adalah nonce, meskipun urutan tetap IVs (misalnya, penghitung) berfungsi dengan baik. Ciphertext sangat mudah ditempa. Tidak ada keamanan CCA. Enkripsi dan dekripsi tidak efisien karena secara inheren berseri. Mengenkripsi secara alami string dengan panjang bit apa pun (tidak diperlukan bantalan). Saya tidak dapat mengidentifikasi kelebihan penting dibandingkan mode CTR.

RKPT : Skema enkripsi berbasis IV, mode ini mencapai ketidakterbandingan dari bit acak dengan asumsi nonce IV. Sebagai skema berbasis nonce aman, mode ini juga dapat digunakan sebagai skema enkripsi probabilistik, dengan IV acak. Kegagalan total privasi jika nonce digunakan kembali pada enkripsi atau dekripsi. Paralelabilitas mode sering membuatnya lebih cepat, dalam beberapa pengaturan jauh lebih cepat, daripada mode kerahasiaan lainnya. Blok bangunan penting untuk skema enkripsi terotentikasi. Secara keseluruhan, biasanya cara terbaik dan paling modern untuk mencapai enkripsi privasi saja.

XTS : Skema enkripsi berbasis IV, mode bekerja dengan menerapkan blockcipher tweakable (aman sebagai PRP kuat) untuk setiap potongan n-bit. Untuk pesan dengan panjang tidak dapat dibagi oleh n, dua blok terakhir diperlakukan secara khusus. Satu-satunya penggunaan mode yang diizinkan adalah untuk mengenkripsi data pada perangkat penyimpanan terstruktur-blok. Lebar sempit PRP yang mendasarinya dan perawatan blok akhir fraksional yang buruk adalah masalah. Lebih efisien tetapi kurang diinginkan daripada blockcipher PRP (secure-block) aman.

MAC (integritas pesan tetapi bukan enkripsi)

ALG1–6 : Kumpulan MAC, semuanya berdasarkan CBC-MAC. Terlalu banyak skema. Beberapa terbukti aman sebagai VIL PRF, beberapa sebagai FIL PRF, dan beberapa tidak memiliki keamanan yang terbukti. Beberapa skema mengakui serangan merusak. Beberapa mode diberi tanggal. Pemisahan kunci tidak cukup diperhatikan untuk mode yang memilikinya. Seharusnya tidak diadopsi secara massal, tetapi secara selektif memilih skema "terbaik" adalah mungkin. Akan lebih baik untuk tidak mengadopsi mode-mode ini, mendukung CMAC. Beberapa MAC ISO 9797-1 distandarisasi dan digunakan secara luas, terutama di perbankan. Versi standar revisi (ISO / IEC FDIS 9797-1: 2010) akan segera dirilis [93].

CMAC : MAC yang didasarkan pada CBC-MAC, modenya terbukti aman (sampai batas ulang tahun) sebagai (VIL) PRF (dengan asumsi blockcipher yang mendasari adalah PRP yang baik). Pada dasarnya biaya minimum untuk skema berbasis CBCMAC. Sifat serial serial masalah dalam beberapa domain aplikasi, dan penggunaan dengan blockcipher 64-bit akan membutuhkan penguncian ulang sesekali. Lebih bersih dari koleksi ISO 9797-1 MAC.

HMAC : MAC yang didasarkan pada fungsi hash kriptografi dan bukan blockcipher (meskipun sebagian besar fungsi hash kriptografis itu sendiri didasarkan pada blockciphers). Mekanisme menikmati batas keamanan yang dapat dibuktikan kuat, meskipun tidak dari asumsi yang lebih disukai. Berbagai varian yang berkaitan erat dalam literatur mempersulit untuk mendapatkan pemahaman tentang apa yang diketahui. Tidak ada serangan merusak yang pernah disarankan. Banyak terstandarisasi dan digunakan.

GMAC : MAC berbasis nonce yang merupakan kasus khusus GCM. Mewarisi banyak karakteristik baik dan buruk GCM. Tetapi persyaratan nonce tidak diperlukan untuk MAC, dan di sini ia membeli sedikit manfaat. Serangan praktis jika tag dipotong ke ≤ 64 bit dan tingkat dekripsi tidak dipantau dan dikurangi. Kegagalan total pada nonce-reuse. Penggunaan tetap tersirat jika GCM diadopsi. Tidak direkomendasikan untuk standardisasi terpisah.

enkripsi terotentikasi (enkripsi dan integritas pesan)

CCM : Skema AEAD berbasis non yang menggabungkan enkripsi mode CTR dan CBC-MAC mentah. Serial, membatasi kecepatan dalam beberapa konteks. Terbukti aman, dengan batas yang baik, dengan asumsi blockcipher yang mendasarinya adalah PRP yang baik. Konstruksi tidak bijaksana yang terbukti melakukan pekerjaan. Lebih mudah diimplementasikan daripada GCM. Dapat digunakan sebagai MAC berbasis nonce. Banyak terstandarisasi dan digunakan.

GCM : Skema AEAD berbasis non yang menggabungkan enkripsi mode CTR dan fungsi hash universal berbasis GF (2128). Karakteristik efisiensi yang baik untuk beberapa lingkungan implementasi. Hasil yang terbukti aman-aman dengan asumsi pemotongan tag minimal. Serangan dan batas keamanan yang dapat dibuktikan buruk dengan adanya pemotongan tag yang substansial. Dapat digunakan sebagai MAC berbasis nonce, yang kemudian disebut GMAC. Pilihan yang dipertanyakan untuk mengizinkan nonces selain 96-bit. Rekomendasikan batasi nonces ke 96-bit dan tag setidaknya 96 bit. Banyak terstandarisasi dan digunakan.

1. Apa pun kecuali ECB.
2. Jika menggunakan CTR, Anda harus menggunakan IV yang berbeda untuk setiap pesan, jika tidak, penyerang dapat mengambil dua ciphertext dan mendapatkan gabungan teks yang tidak terenkripsi. Alasannya adalah bahwa mode CTR pada dasarnya mengubah cipher blok menjadi stream cipher, dan aturan pertama dari stream cipher adalah jangan pernah menggunakan Key + IV yang sama dua kali.
3. Sebenarnya tidak ada banyak perbedaan dalam seberapa sulit mode untuk diimplementasikan. Beberapa mode hanya memerlukan cipher blok untuk beroperasi dalam arah enkripsi. Namun, sebagian besar cipher blok, termasuk AES, tidak memerlukan lebih banyak kode untuk mengimplementasikan dekripsi.
4. Untuk semua mode sandi, penting untuk menggunakan IV yang berbeda untuk setiap pesan jika pesan Anda bisa identik dalam beberapa byte pertama, dan Anda tidak ingin seorang penyerang mengetahui hal ini.

Sudahkah Anda mulai dengan membaca informasi ini di Wikipedia - Blok mode operasi cipher ? Kemudian ikuti tautan referensi di Wikipedia ke NIST: Rekomendasi untuk Mode Operasi Blok Cipher .

Anda mungkin ingin memilih berdasarkan apa yang tersedia secara luas. Saya memiliki pertanyaan yang sama dan ini adalah hasil dari penelitian terbatas saya.

Keterbatasan perangkat keras

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Keterbatasan sumber terbuka

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Gunakan-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Saya tahu satu aspek: Meskipun CBC memberikan keamanan yang lebih baik dengan mengubah IV untuk setiap blok, itu tidak berlaku untuk mengakses konten terenkripsi secara acak (seperti hard disk terenkripsi).

Jadi, gunakan CBC (dan mode sekuensial lainnya) untuk aliran sekuensial dan ECB untuk akses acak.