Hangileri hangi durumlarda tercih edilir?

Çeşitli modlar için değerlendirme kriterleri listesini görmek ve belki de her kriterin uygulanabilirliğini tartışmak istiyorum.

Örneğin, kriterlerden birinin 802.11 ağ bağdaştırıcıları gibi mikrokod gömülü sistemler için önemli olan şifreleme ve şifre çözme için "kodun boyutu" olduğunu düşünüyorum. CBC uygulamak için gereken kod, TO için gerekli olandan çok daha küçükse (bunun doğru olduğunu bilmiyorum, sadece bir örnek), o zaman neden daha küçük kodlu modun tercih edileceğini anlayabiliyordum. Ancak bir sunucuda çalışan bir uygulama yazıyorsam ve kullandığım AES kütüphanesi yine de CBC ve CTR'yi uyguluyorsa, bu kriter önemsizdir.

"Değerlendirme ölçütleri listesi ve her kriterin uygulanabilirliği" ile ne demek istediğimi görün ??

Bu gerçekten programlama ile ilgili değil, algoritma ile ilgili.

• Aynı anahtarla birden fazla veri bloğunu şifreliyorsanız ECB kullanılmamalıdır.

• CBC, OFB ve CFB benzerdir, ancak OFB / CFB daha iyidir, çünkü kod alanından tasarruf edebilen sadece şifrelemeye ihtiyacınız vardır ve şifre çözmeye değil.

• CBC / OFB / CFB yerine iyi bir paralelleştirme (yani hız) istiyorsanız CTR kullanılır.

• XTS modu, rasgele erişilebilir verileri (sabit disk veya RAM gibi) kodluyorsanız en yaygın moddur.

• OCB, tek bir geçişte şifreleme ve kimlik doğrulamaya izin verdiği için açık ara en iyi moddur. Ancak ABD'de patentler var.

Gerçekten bilmeniz gereken tek şey ECB'nin sadece 1 bloğu şifrelemediğiniz sürece kullanılmamasıdır. Bir akışı değil, rastgele erişilen verileri şifreliyorsanız XTS kullanılmalıdır.

• Sen DAİMA benzersiz kullanmalıdır IV 'şifrelemek her zamanı ve onlar olmalıdır rastgele . Rastgele olduklarını garanti edemezseniz , OCB'yi kullanın , çünkü IV değil sadece nonce gerektirir ve belirgin bir fark vardır. Bir Nonce insanlar sonrakini tahmin edebilirsiniz eğer bir güvenliği düşmemesine IV bu soruna neden olabilir.

Kendi kriptografinizi uygulayamıyorsanız lütfen uzun ve zor düşünün

Meselenin çirkin gerçeği, bu soruyu soruyorsanız, muhtemelen güvenli bir sistem tasarlayamayacak ve uygulayamayacağınızdır.

Demek istediğim şunu açıklayayım: Bir web uygulaması oluşturduğunuzu ve bazı oturum verilerini depolamanız gerektiğini düşünün. Her kullanıcıya bir oturum kimliği atayabilir ve oturum verilerini bir karma harita eşleme oturum kimliğinde sunucuda oturum verilerine depolayabilirsiniz. Ama sonra sunucudaki bu sinir bozucu durumla uğraşmak zorundasınız ve bir noktada birden fazla sunucuya ihtiyacınız varsa işler dağınık hale gelecektir. Bunun yerine, oturum verilerini istemci tarafında bir çerezde saklama fikriniz vardır. Elbette şifreleyeceksiniz, böylece kullanıcı verileri okuyamaz ve değiştiremez. Peki hangi modu kullanmalısınız? Buraya gelip üst cevabı okuyorsun (seni myforwik'te söylediğim için üzgünüm). Birincisi - ECB - sizin için değil, birden fazla bloğu şifrelemek istiyorsunuz, diğeri - CBC - iyi görünüyor ve CTR'nin paralelliğine ihtiyacınız yok, rastgele erişime ihtiyacınız yok, bu yüzden hiçbir XTS ve patent bir PITA değildir, bu yüzden OCB yoktur. Kripto kütüphanenizi kullanarak, sadece blok boyutunun katlarını şifreleyebileceğiniz için biraz dolguya ihtiyacınız olduğunu fark edersiniz. Sen seçPKCS7 çünkü bazı ciddi şifreleme standartlarında tanımlanmıştır. Rastgele IV ve güvenli bir blok şifreleme ile kullanıldığında CBC'nin güvenilir olduğu bir yerde okuduktan sonra , hassas verilerinizi istemci tarafında saklasanız bile rahatça dinlenirsiniz.

Hizmetinizin gerçekten önemli bir boyuta ulaşmasından yıllar sonra, bir BT güvenlik uzmanı sorumlu bir açıklamada sizinle iletişim kurar. Dolgu kehanet saldırısı kullanarak tüm çerezlerin şifresini çözebileceğini söylüyor , çünkü dolgu bir şekilde kırılırsa kodunuz bir hata sayfası üretir.

Bu varsayımsal bir senaryo değildir: Microsoft, ASP.NET'te birkaç yıl öncesine kadar tam olarak bu kusura sahipti.

Sorun şu ki, kriptografi ile ilgili bir çok tuzak var ve layman için güvenli görünen ancak bilgili bir saldırgan için kırılması önemsiz bir sistem kurmak son derece kolaydır.

Verileri şifrelemeniz gerekiyorsa ne yapmalısınız?

Canlı bağlantılar için TLS kullanın (sertifikanın ana bilgisayar adını ve yayıncı zincirini kontrol ettiğinizden emin olun). TLS'yi kullanamıyorsanız, sisteminizin göreviniz için sunduğu en üst düzey API'yi arayın ve sunduğu garantileri anladığınızdan ve garanti etmediklerinden daha önemli olduğundan emin olun. Yukarıdaki örnekte, Play gibi bir çerçeve istemci tarafı depolama olanakları sunar , ancak bir süre sonra depolanan verileri geçersiz kılmaz ve istemci taraf durumunu değiştirirseniz, bir saldırgan siz fark etmeden önceki durumu geri yükleyebilir.

Yüksek düzeyde bir soyutlama yoksa yüksek düzeyde bir kripto kütüphanesi kullanın. Öne çıkan bir örnek NaCl'dir ve birçok dil bağlaması olan taşınabilir bir uygulama Sodyum'dur . Böyle bir kütüphaneyi kullanarak şifreleme modlarını vb. Önemsemeniz gerekmez, ancak kullanım ayrıntılarında daha önce iki kez bir nonce kullanmamak gibi daha yüksek bir soyutlamadan daha dikkatli olmanız gerekir.

Herhangi bir nedenden ötürü yüksek seviyeli bir kripto kütüphanesi kullanamıyorsanız, örneğin mevcut sistemle belirli bir şekilde etkileşim kurmanız gerektiğinden, kendinizi kapsamlı bir şekilde eğitmenin bir yolu yoktur. Ferguson, Kohno ve Schneier'in Şifreleme Mühendisliği'ni okumanızı tavsiye ederim . Lütfen gerekli altyapıya sahip olmadan güvenli bir sistem kurabileceğinize inanın. Kriptografi son derece incedir ve bir sistemin güvenliğini test etmek neredeyse imkansızdır.

Modların karşılaştırılması

Yalnızca şifreleme:

• Dolgu gerektiren modlar : Örnekte olduğu gibi, dolgu genellikle tehlikeli olabilir, çünkü kâhin saldırılarını doldurma olasılığını açar. En kolay savunma, şifre çözmeden önce her iletinin kimliğini doğrulamaktır. Aşağıya bakınız.
  • ECB her veri bloğunu bağımsız olarak şifreler ve aynı düz metin bloğu aynı şifreleme bloğuna neden olur. Bunun neden ciddi bir sorun olduğunu görmek için ECB Wikipedia sayfasındaki ECB şifreli Tux görüntüsüne bakın. ECB'nin kabul edilebileceği herhangi bir kullanım durumu bilmiyorum.
  • CBC'nin bir IV'si vardır ve bu nedenle bir mesaj her şifrelendiğinde rasgeleliğe ihtiyaç duyar, mesajın bir kısmını değiştirmek için değişiklikten sonra her şeyi yeniden şifrelemek gerekir, bir şifre metnindeki iletim hataları düz metni tamamen yok eder ve bir sonraki bloğun şifresini çözer, şifre çözme paralelleştirilebilir / şifreleme yapılamaz, düz metin belirli bir dereceye kadar biçimlendirilebilir - bu bir sorun olabilir .
• Akış şifreleme modları : Bu modlar, düz metne bağlı olabilecek veya olmayabilir, sahte bir veri akışı oluşturur. Akış şifrelerine genel olarak benzer şekilde, üretilen sahte rasgele akış şifreleme metnini üretmek için düz metinle XORed edilir. İstediğiniz kadar rastgele akışın bitlerini kullanabileceğiniz için dolguya hiç ihtiyacınız yok. Bu basitliğin dezavantajı, şifrelemenin tamamen biçimlendirilebilir olmasıdır, şifre çözmenin bir saldırgan tarafından düz metin p1, şifreli metin c1 ve sahte rasgele akış r gibi saldırgan tarafından değiştirilebileceği anlamına gelir ve saldırgan, bir şifreli metnin şifre çözülmesi için bir fark d seçebilir c2 = c1 dd p2 = p1⊕d, p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Ayrıca, aynı sahte rasgele akış asla iki ciphertext için iki kez kullanılmamalıdır c1 = p1⊕r ve c2 = p2⊕r, bir saldırgan iki düzeksteki xor'u c1⊕c2 = p1⊕r⊕p2⊕r = olarak hesaplayabilir p1⊕p2. Bu, orijinal mesaj bir saldırgan tarafından edinilmişse, mesajın değiştirilmesinin tamamen yeniden şifreleme gerektirdiği anlamına da gelir. Aşağıdaki buhar şifreleme modlarının tümü sadece blok şifrenin şifreleme işlemine ihtiyaç duyar, bu nedenle şifreye bağlı olarak bu, son derece dar ortamlarda biraz (silikon veya makine kodu) alan tasarrufu sağlayabilir.
  • TO basittir, düz metinden bağımsız bir sahte rasgele akış oluşturur, üst üste binmenin önlenmesi için farklı mesajlar / IV'lerden sayılarak farklı sahte rasgele akışlar elde edilir, böylece çakışma önlenir, nonces mesaj şifrelemesi kullanılır. İleti başına mümkün olmayan rastgele, şifre çözme ve şifreleme paralelleştirilebilir, iletim hataları sadece yanlış bitleri etkiler ve daha fazlası değil
  • OFB ayrıca düz metinden bağımsız bir sözde rastgele akış oluşturur, her mesaj için farklı bir nonce veya rastgele IV ile başlanarak farklı sözde rastgele akışlar elde edilir, mesaj olmadan mesaj şifrelemesi kullanan CTR ile ne şifreleme ne de şifre çözme paralelleştirilebilir CTR iletim hatalarında olduğu gibi rastgele olma, yalnızca yanlış bitleri etkiler ve daha fazlası değil
  • CFB'nin sözde rasgele akışı düz metne bağlıdır, her mesaj için farklı bir nonce veya rastgele IV gereklidir, CTR ve OFB gibi nonces mesaj şifreleme kullanarak mesaj rastgele olmadan mümkündür, şifre çözme paralelleştirilebilir / şifreleme değildir, iletim hataları tamamen Aşağıdaki bloğu yok et, ancak yalnızca geçerli bloktaki yanlış bitleri etkile
• Disk şifreleme modları : Bu modlar, dosya sistemi soyutlamasının altındaki verileri şifrelemek için uzmanlaşmıştır. Verimlilik nedeniyle, diskteki bazı verilerin değiştirilmesi için yalnızca en fazla bir disk bloğunun (512 bayt veya 4kib) yeniden yazılması gerekir. Diğerlerinden çok farklı kullanım senaryolarına sahip oldukları için bu sorunun kapsamı dışındadırlar. Bunları blok düzeyinde disk şifrelemesi dışında bir şey için kullanmayın . Bazı üyeler: XEX, XTS, LRW.

Kimliği doğrulanmış şifreleme:

Oracle saldırılarını ve şifre metninde değişiklik yapılmasını önlemek için, şifre metninde bir mesaj kimlik doğrulama kodu (MAC) hesaplanabilir ve yalnızca değiştirilmemişse şifresi çözülebilir. Buna encrypt-then-mac denir ve başka herhangi bir sıraya göre tercih edilmelidir . Çok az kullanım durumu dışında, özgünlük gizlilik kadar önemlidir (ikincisi şifrelemenin amacıdır). Kimliği doğrulanmış şifreleme şemaları (ilişkili verilerle (AEAD)), iki parçalı şifreleme ve kimlik doğrulama işlemini, işlemde kimlik doğrulama etiketi üreten tek bir blok şifreleme modunda birleştirir. Çoğu durumda bu hızın iyileşmesine neden olur.

• CCM , TO modu ve bir CBC-MAC'in basit bir kombinasyonudur. Blok başına iki blok şifreleme şifresi kullanmak çok yavaştır.
• OCB daha hızlıdır ancak patentlerle çevrilidir. Özgür (özgürlükte olduğu gibi) veya askeri olmayan yazılımlar için patent sahibi ücretsiz bir lisans vermiştir .
• GCM , 2 ^ 128 elementli Galois alanı üzerinde bir MAC olan CTR modu ve GHASH'ın çok hızlı ama tartışmasız karmaşık bir kombinasyonudur. TLS 1.2 gibi önemli ağ standartlarında geniş kullanımı, Intel'in GHASH hesaplamasını hızlandırmak için tanıttığı özel bir talimatla yansıtılmaktadır .

Öneri:

Kimlik doğrulamanın önemi göz önüne alındığında, çoğu kullanım durumu için (disk şifreleme amaçları hariç) aşağıdaki iki blok şifreleme modunu öneriyorum: Verilerin asimetrik bir imza ile doğrulanması halinde CBC kullanın, aksi takdirde GCM kullanın.

Resmi bir analiz, 2011 yılında Phil Rogaway tarafından yapılmıştır buraya . Bölüm 1.6, burada yazıya döktüğüm, kalın harflerle kendi vurgularımı eklediğim bir özet verir (eğer sabırsızsanız, tavsiyesi CTR modunu kullanmaktır, ancak aşağıda mesaj bütünlüğü ve şifreleme hakkındaki paragrafları okumanızı öneririz).

Bunların çoğunun IV'ün rasgele olmasını gerektirdiğini, bu da öngörülemez olduğu anlamına gelir ve bu nedenle kriptografik güvenlikle oluşturulması gerektiğini unutmayın. Ancak, bazıları sadece bu özelliği talep etmeyen bir "nonce" gerektirir, bunun yerine sadece yeniden kullanılmamasını gerektirir. Bu nedenle, bir nonce'ye dayanan tasarımlar, yapmayan tasarımlardan daha az hataya eğilimlidir (ve bana inanıyorum, CBC'nin uygun IV seçimi ile uygulanmadığı birçok durum gördüm). Bu yüzden Rogaway "IV bir nonce olduğunda gizlilik elde edilemez" gibi bir şey söylediğinde cesur eklediğimi göreceksiniz, bu da IV kriptografik olarak güvenli (öngörülemez) seçerseniz sorun olmaz demektir. Ancak bunu yapmazsanız, iyi güvenlik özelliklerini kaybedersiniz. Bu modlardan herhangi biri için asla IV'ü tekrar kullanmayın .

Ayrıca, mesaj bütünlüğü ve şifreleme arasındaki farkı anlamak da önemlidir. Şifreleme verileri gizler, ancak saldırgan şifrelenmiş verileri değiştirebilir ve mesaj bütünlüğünü kontrol etmezseniz sonuçlar yazılımınız tarafından kabul edilebilir. Geliştiricinin "ancak değiştirilen veriler şifre çözme işleminden sonra çöp olarak geri döneceğini" söyleyecek olsa da, iyi bir güvenlik mühendisi çöpün yazılımda olumsuz davranışlara neden olma olasılığını bulacaktır ve ardından bu analizi gerçek bir saldırıya dönüştürecektir. Şifrelemenin kullanıldığı birçok durum gördüm ancak mesaj bütünlüğünün şifrelemeden daha fazlasına ihtiyacı vardı. Neye ihtiyacınız olduğunu anlayın.

GCM'nin hem şifreleme hem de mesaj bütünlüğü olmasına rağmen, çok kırılgan bir tasarım olduğunu söylemeliyim: Bir IV'ü tekrar kullanırsanız, vidalanırsınız - saldırgan anahtarınızı kurtarabilir. Diğer tasarımlar daha az kırılgandır, bu yüzden şahsen GCM'yi uygulamada gördüğüm kötü şifreleme kodunun miktarına göre önermekten korkuyorum.

Hem mesaj bütünlüğüne hem de şifrelemeye ihtiyacınız varsa, iki algoritmayı birleştirebilirsiniz: genellikle CBC'yi HMAC ile görüyoruz, ancak kendinizi CBC'ye bağlamak için bir neden yok. Bilmeniz gereken önemli şey önce şifrelemek, daha sonra şifrelenmiş içeriği MAC'dir, tersi değil. Ayrıca, IV'ün MAC hesaplamasının bir parçası olması gerekir.

IP sorunlarının farkında değilim.

Şimdi Profesör Rogaway'in iyi şeylerine:

Şifreleme modlarını, şifrelemeyi engelle ancak ileti bütünlüğünü engelle

ECB : Bir blockcipher, mod, her bir n-bit parçasını ayrı ayrı şifreleyerek n bitin katları olan mesajları şifreler. Güvenlik özellikleri zayıftır , yöntem hem blok konumları hem de zaman boyunca blokların eşitliğini sızdırır. Önemli miras değerine ve diğer şemalar için bir yapı taşı olarak değere sahip olmakla birlikte, mod kendi başına genel olarak arzu edilen herhangi bir güvenlik hedefine ulaşmaz ve büyük bir dikkatle kullanılmalıdır; ECB “genel amaçlı” bir gizlilik modu olarak görülmemelidir .

CBC : IV tabanlı bir şifreleme şeması, mod, olasılıklı bir şifreleme şeması olarak güvenlidir ve rastgele bir IV varsayarak rastgele bitlerden ayırt edilemezlik sağlar. IV sadece bir nonce ise veya standart tarafından yanlış bir şekilde önerildiği gibi, şema tarafından kullanılan aynı anahtar altında şifrelenmemişse, gizlilik elde edilemez . Şifrelemeler oldukça yumuşaktır. Seçili şifreli metin saldırısı (CCA) güvenliği yok. Birçok dolgu yöntemi için doğru doldurma kehaneti varlığında gizlilik kaybedilir. Doğası gereği seri olmaktan şifreleme verimsiz. Yaygın olarak kullanılan modun yalnızca gizlilik güvenlik özellikleri sık sık yanlış kullanıma neden olur. CBC-MAC algoritmaları için yapı taşı olarak kullanılabilir. TO moduna göre önemli bir avantaj tanımlayamıyorum.

CFB : IV tabanlı bir şifreleme şeması, mod, olasılıklı bir şifreleme şeması olarak güvenlidir ve rastgele bir IV varsayarak rastgele bitlerden ayırt edilemezlik sağlar. IV öngörülebilirse veya standart tarafından yanlış bir şekilde önerildiği gibi, şema tarafından kullanılan anahtarla şifrelenmemiş bir kişi tarafından yapılmışsa gizlilik elde edilemez . Şifrelemeleri biçimlendirilebilir. CCA güvenliği yok. Doğası gereği seri olmaktan şifreleme verimsiz. Şema, s parametresine bağlıdır, 1 ≤ s ≤ n, tipik olarak s = 1 veya s = 8. Mod ilginç bir “kendini senkronizasyon” özelliğine sahiptir; herhangi bir sayıda s-bit karakterin şifreli metne eklenmesi veya silinmesi, doğru şifre çözmeyi yalnızca geçici olarak bozar.

OFB : IV tabanlı bir şifreleme şeması, mod, olasılıklı bir şifreleme şeması olarak güvenlidir ve rastgele bir IV varsayarak rastgele bitlerden ayırt edilemezlik sağlar. Sabit bir IV dizisi (örn., Bir sayaç) düzgün çalışmasına rağmen, IV bir nonce ise gizlilik elde edilemez. Şifrelemeler oldukça yumuşaktır. CCA güvenliği yok. Şifreleme ve şifre çözme, doğası gereği seri olmaktan yetersizdir. Herhangi bir bit uzunluğundaki dizeleri yerel olarak şifreler (dolgu gerekmez). TO moduna göre önemli bir avantaj tanımlayamıyorum.

CTR : IV tabanlı bir şifreleme şeması olan mod, IV olmayan bir varsayımla rastgele bitlerden ayırt edilemezlik sağlar. Güvenli bir nonce tabanlı şema olarak, mod rastgele bir IV ile olasılıklı bir şifreleme şeması olarak da kullanılabilir. Bir nonce şifreleme veya şifre çözme işleminde yeniden kullanılırsa gizliliğin tamamen başarısız olması. Modun paralelleştirilebilirliği genellikle bazı ayarlarda diğer gizlilik modlarından daha hızlıdır. Kimliği doğrulanmış şifreleme düzenleri için önemli bir yapı taşıdır. Genel olarak, yalnızca gizlilik şifrelemesini elde etmenin genellikle en iyi ve en modern yolu.

XTS : IV tabanlı bir şifreleme düzeni olan mod, her n-bit yığınına bir tweakable blok diski (güçlü bir PRP olarak güvenli) uygulayarak çalışır. Uzunlukları n ile bölünemeyen mesajlar için, son iki blok özel olarak ele alınır. Modun izin verilen tek kullanımı, blok yapılı bir depolama aygıtındaki verileri şifrelemek içindir. Altta yatan PRP'nin dar genişliği ve fraksiyonel son blokların kötü tedavisi problemlerdir. Daha etkili ancak (geniş bloklu) bir PRP-güvenli blokipere göre daha az arzu edilir.

MAC'ler (mesaj bütünlüğü ancak şifreleme değil)

ALG1–6 : Hepsi CBC- MAC'e dayanan bir MAC koleksiyonu. Çok fazla şema. Bazıları VIL PRF'leri, bazıları da FIL PRF'leri ve bazılarının kanıtlanabilir güvenliği yoktur. Bazı planlar zarar verici saldırıları kabul etmektedir. Bazı modlar tarihli. Anahtar ayrımına sahip modlar için yetersiz bir şekilde katılır. Toplu olarak kabul edilmemeli, ancak “en iyi” şemaların seçilerek seçilmesi mümkündür. Bu modlardan hiçbirini CMAC lehine kabul etmek de iyi olur. ISO 9797-1 MAC'lerin bazıları, özellikle bankacılıkta yaygın olarak standartlaştırılmış ve kullanılmaktadır. Standardın gözden geçirilmiş bir versiyonu (ISO / IEC FDIS 9797-1: 2010) yakında yayınlanacaktır [93].

CMAC : CBC-MAC tabanlı bir MAC, mod (VIL) PRF (temeldeki blokiperin iyi bir PRP olduğu varsayılarak) olarak güvenli bir şekilde (doğum gününe bağlı) güvenlidir. CBCMAC tabanlı bir şema için esasen minimum ek yük. Doğası gereği, seri uygulama bazı uygulama alanlarında bir sorun ve 64 bitlik bir blok disiplinin kullanılması, zaman zaman yeniden anahtarlama gerektirecektir. ISO 9797-1 MAC koleksiyonundan daha temiz.

HMAC : Bir blok şifreleme yerine bir şifreleme karma işlevine dayanan bir MAC (çoğu şifreleme karma işlevinin kendisi blok şifreleyicilere dayanmasına rağmen). Mekanizma, tercih edilen varsayımlardan olmasa da, güçlü kanıtlanabilir güvenlik sınırlarına sahiptir. Literatürdeki yakından ilişkili çok sayıda varyant, bilinenlerin anlaşılmasını zorlaştırmaktadır. Hiçbir zararlı saldırı önerilmemiştir. Yaygın olarak standartlaştırılmış ve kullanılır.

GMAC : GCM'nin özel bir örneği olan nonce tabanlı bir MAC. GCM'nin iyi ve kötü özelliklerinin çoğunu miras alır. Ancak, MAC için gereksiz gereksinim yoktur ve burada çok az fayda sağlar. Etiketler b 64 bite kesilirse ve şifre çözme derecesi izlenmez ve kısıtlanmazsa pratik saldırılar. Tekrar kullanılmadığında tam arıza. GCM kabul edilirse kullanım zaten örtüktür. Ayrı standartlaştırma için önerilmez.

kimliği doğrulanmış şifreleme (hem şifreleme hem de mesaj bütünlüğü)

CCM : TO modu şifrelemesini ve ham CBC-MAC'i birleştiren nonce tabanlı bir AEAD şeması. Doğası gereği seri, bazı bağlamlarda hızı sınırlar. Altta yatan blokiperin iyi bir PRP olduğunu varsayarak, iyi sınırlarla, güvenli bir şekilde güvence altına alın. İşi açıkça gösteren gayri meşru yapı. GCM'den daha basit uygulanması. Nonce tabanlı bir MAC olarak kullanılabilir. Yaygın olarak standartlaştırılmış ve kullanılır.

GCM : TO modu şifrelemesini ve GF (2128) tabanlı bir evrensel karma işlevini birleştiren nonce tabanlı bir AEAD şeması. Bazı uygulama ortamları için iyi verimlilik özellikleri. Minimum etiket kesimi varsayıldığında iyi güvenli sonuçlar. Önemli etiket kesilmeleri durumunda saldırılar ve zayıf kanıtlanabilir güvenlik sınırları. Daha sonra GMAC olarak adlandırılan nonce tabanlı bir MAC olarak kullanılabilir. 96 bit dışındaki duruşlara izin vermek için şüpheli bir seçim. Nüfuzları 96 bitle ve etiketleri en az 96 bitle sınırlamanızı öneririz. Yaygın olarak standartlaştırılmış ve kullanılır.

1. ECB dışında her şey.
2. TO kullanıyorsanız, her mesaj için farklı bir IV kullanmanız zorunludur, aksi takdirde saldırganın iki şifre alabilir ve birleştirilmiş şifrelenmemiş düz metin elde edebilirsiniz. Bunun nedeni, TO modunun bir blok şifresini bir akış şifresine dönüştürmesi ve akış şifrelemelerinin ilk kuralı asla aynı Key + IV'ü iki kez kullanmamaktır.
3. Modların uygulanmasının ne kadar zor olduğu konusunda gerçekten çok fazla fark yoktur. Bazı modlar sadece blok şifrenin şifreleme yönünde çalışmasını gerektirir. Bununla birlikte, AES dahil olmak üzere çoğu blok şifresi, şifre çözme uygulamak için daha fazla kod almaz.
4. Tüm şifre modlarında, mesajlarınız ilk birkaç baytta aynı olabilirse ve bir saldırganın bunu bilmesini istemiyorsanız, her mesaj için farklı IV'ler kullanmak önemlidir.

Wikipedia - Blok şifreleme çalışma modları hakkındaki bu bilgileri okuyarak başladınız mı ? Ardından Wikipedia'dan NIST'e referans bağlantısını izleyin : Blok Şifreleme Çalışma Modları için öneri .

Yaygın olarak mevcut olanlara göre seçim yapmak isteyebilirsiniz. Aynı soruyu sordum ve sınırlı araştırmamın sonuçları burada.

Donanım sınırlamaları

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

Açık kaynak sınırlamaları

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-Use-AES-Library

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

Ben bir yönü biliyorum: CBC her blok için IV değiştirerek daha iyi güvenlik sağlar, ancak rasgele erişilen şifreli içerik (şifreli sabit disk gibi) için geçerli değildir.

Bu nedenle, sıralı akışlar için CBC (ve diğer sıralı modlar) ve rastgele erişim için ECB kullanın.