Które z nich są preferowane w jakich okolicznościach?

Chciałbym zobaczyć listę kryteriów oceny dla różnych trybów i być może dyskusję na temat zastosowania każdego kryterium.

Na przykład myślę, że jednym z kryteriów jest „rozmiar kodu” do szyfrowania i deszyfrowania, co jest ważne w przypadku systemów osadzonych z mikrokodami, takich jak karty sieciowe 802.11. JEŻELI kod wymagany do wdrożenia CBC jest znacznie mniejszy niż wymagany dla CTR (nie wiem, czy to prawda, to tylko przykład), wtedy mogłem zrozumieć, dlaczego tryb z mniejszym kodem byłby preferowany. Ale jeśli piszę aplikację, która działa na serwerze, a używana przeze mnie biblioteka AES implementuje zarówno CBC, jak i CTR, to kryterium nie ma znaczenia.

Zobacz, co rozumiem przez „listę kryteriów oceny i zastosowanie każdego kryterium”?

To nie jest tak naprawdę związane z programowaniem, ale jest związane z algorytmem.

• EBC nie powinien być stosowany w przypadku szyfrowania więcej niż jednego bloku danych za pomocą tego samego klucza.

• CBC, OFB i CFB są podobne, jednak OFB / CFB jest lepszy, ponieważ potrzebujesz tylko szyfrowania, a nie deszyfrowania, co może zaoszczędzić miejsce na kod.

• CTR jest używany, jeśli chcesz dobrej równoległości (tj. Prędkości), zamiast CBC / OFB / CFB.

• Tryb XTS jest najbardziej powszechny, jeśli kodujesz losowo dostępne dane (takie jak dysk twardy lub pamięć RAM).

• OCB jest zdecydowanie najlepszym trybem, ponieważ umożliwia szyfrowanie i uwierzytelnianie w jednym przejściu. Istnieją jednak patenty na to w USA.

Jedyną rzeczą, którą naprawdę musisz wiedzieć, jest to, że EBC nie będzie używany, chyba że szyfrujesz tylko 1 blok. XTS powinien być używany, jeśli szyfrujesz losowo dostępne dane, a nie strumień.

• ZAWSZE powinieneś używać unikalnych IV za każdym razem, gdy szyfrujesz, i powinny być losowe . Jeśli nie możesz zagwarantować, że są losowe , użyj OCB, ponieważ wymaga tylko nonce , a nie IV , i istnieje wyraźna różnica. Nonce nie spadnie bezpieczeństwo jeśli ludzie mogą odgadnąć następny An IV może być przyczyną tego problemu.

Zastanów się długo i ciężko, jeśli nie możesz poradzić sobie z implementacją własnej kryptografii

Brzydka prawda jest taka, że ​​jeśli zadajesz to pytanie, prawdopodobnie nie będziesz w stanie zaprojektować i wdrożyć bezpiecznego systemu.

Pozwól, że zilustruję mój punkt widzenia: wyobraź sobie, że budujesz aplikację internetową i potrzebujesz przechowywać dane sesji. Każdemu użytkownikowi można przypisać identyfikator sesji i przechowywać dane sesji na serwerze w identyfikatorze sesji mapowania skrótu na dane sesji. Ale wtedy musisz poradzić sobie z tym nieznośnym stanem na serwerze i jeśli w pewnym momencie będziesz potrzebować więcej niż jednego serwera, sprawy się popsują. Zamiast tego masz pomysł, aby przechowywać dane sesji w pliku cookie po stronie klienta. Zaszyfrujesz go oczywiście, aby użytkownik nie mógł odczytać danych i nimi manipulować. Więc jakiego trybu należy użyć? Jadąc tutaj, przeczytałeś najwyższą odpowiedź (przepraszam, że wyróżniłem cię myforwik). Pierwszy z nich - EBC - nie jest dla Ciebie, chcesz zaszyfrować więcej niż jeden blok, następny - CBC - brzmi dobrze i nie potrzebujesz równoległości CTR, nie potrzebujesz dostępu losowego, więc żadne XTS i patenty nie są PITA, więc nie ma OCB. Korzystając z biblioteki kryptograficznej, zdajesz sobie sprawę, że potrzebujesz dopełnienia, ponieważ możesz szyfrować tylko wielokrotności rozmiaru bloku. Ty wybieraszPKCS7, ponieważ został zdefiniowany w niektórych poważnych standardach kryptografii. Po przeczytaniu gdzieś, że CBC jest pewnie bezpieczny, jeśli jest używany z losowym IV i bezpiecznym szyfrem blokowym, odpoczywasz, nawet jeśli przechowujesz swoje wrażliwe dane po stronie klienta.

Wiele lat później, kiedy Twoja usługa rzeczywiście osiągnęła znaczny rozmiar, specjalista ds. Bezpieczeństwa IT skontaktuje się z Tobą w odpowiedzialny sposób. Mówi ci, że może odszyfrować wszystkie twoje pliki cookie za pomocą ataku padding oracle , ponieważ twój kod wyświetla stronę błędu, jeśli wypełnienie jest w jakiś sposób zepsute.

To nie jest hipotetyczny scenariusz: Microsoft miał dokładnie taką wadę w ASP.NET jeszcze kilka lat temu.

Problem polega na tym, że istnieje wiele pułapek związanych z kryptografią i niezwykle łatwo jest zbudować system, który wygląda bezpiecznie dla laika, ale jest prosty do złamania dla znającego się na rzeczy napastnika.

Co zrobić, jeśli musisz zaszyfrować dane

W przypadku połączeń na żywo użyj protokołu TLS (sprawdź nazwę hosta certyfikatu i łańcuch wydawcy). Jeśli nie możesz korzystać z TLS, poszukaj interfejsu API najwyższego poziomu, który system ma do zaoferowania, i upewnij się, że rozumiesz oferowane przez niego gwarancje i, co ważniejsze, to, czego nie gwarantuje. W powyższym przykładzie platforma, taka jak Play, oferuje funkcje przechowywania po stronie klienta , jednak nie unieważnia przechowywanych danych po pewnym czasie, a jeśli zmienisz stan po stronie klienta, osoba atakująca może przywrócić poprzedni stan bez powiadomienia.

Jeśli nie jest dostępna abstrakcja wysokiego poziomu, użyj biblioteki kryptograficznej wysokiego poziomu. Wybitnym przykładem jest NaCl, a przenośną implementacją z wieloma powiązaniami językowymi jest Sodium . Korzystając z takiej biblioteki, nie musisz przejmować się trybami szyfrowania itp., Ale musisz być jeszcze bardziej ostrożny w kwestii szczegółów użycia niż z abstrakcją wyższego poziomu, jak w przypadku dwukrotnego użycia nonce.

Jeśli z jakiegoś powodu nie możesz użyć wysokopoziomowej biblioteki kryptograficznej, na przykład ponieważ musisz wchodzić w interakcje z istniejącym systemem w określony sposób, nie ma możliwości dokładnej edukacji. Polecam lekturę inżynierii kryptografii autorstwa Fergusona, Kohno i Schneiera . Nie daj się zwieść przekonaniu, że możesz zbudować bezpieczny system bez niezbędnego zaplecza. Kryptografia jest niezwykle subtelna i prawie niemożliwe jest przetestowanie bezpieczeństwa systemu.

Porównanie trybów

Tylko szyfrowanie:

• Tryby wymagające paddingu : Podobnie jak w przykładzie, padding może być niebezpieczny, ponieważ otwiera możliwość atakowania oracle. Najłatwiejszą obroną jest uwierzytelnienie każdej wiadomości przed deszyfrowaniem. Patrz poniżej.
  • EBC szyfruje każdy blok danych niezależnie, a ten sam blok tekstu jawnego spowoduje powstanie tego samego bloku tekstu zaszyfrowanego. Spójrz na zaszyfrowany przez EBC obraz Tux na stronie EBC w Wikipedii, aby zobaczyć, dlaczego jest to poważny problem. Nie znam żadnego przypadku użycia, w którym EBC byłby do przyjęcia.
  • CBC ma IV, a zatem potrzebuje losowości za każdym razem, gdy wiadomość jest szyfrowana, zmiana części wiadomości wymaga ponownego zaszyfrowania wszystkiego po zmianie, błędy transmisji w jednym bloku tekstu zaszyfrowanego całkowicie niszczą zwykły tekst i zmieniają deszyfrowanie następnego bloku, deszyfrowanie może być zrównoleglony / szyfrowanie nie, tekst jawny jest w pewnym stopniu plastyczny - może to stanowić problem .
• Tryby szyfrowania strumieniowego : tryby te generują pseudolosowy strumień danych, który może, ale nie musi zależeć od zwykłego tekstu. Podobnie jak w przypadku szyfrów strumieniowych generowany pseudolosowy strumień jest generowany XOR za pomocą zwykłego tekstu w celu wygenerowania tekstu zaszyfrowanego. Ponieważ możesz użyć tyle bitów losowego strumienia, ile chcesz, w ogóle nie potrzebujesz wypełnienia. Wadą tej prostoty jest to, że szyfrowanie jest całkowicie plastyczne, co oznacza, że ​​osoba atakująca może zmienić deszyfrowanie w dowolny sposób, jak w przypadku tekstu jawnego p1, tekstu zaszyfrowanego c1 i pseudolosowego strumienia r, a osoba atakująca może wybrać różnicę d taką, że deszyfrowanie tekstu zaszyfrowanego c2 = c1⊕d oznacza p2 = p1⊕d, ponieważ p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Również ten sam pseudolosowy strumień nigdy nie może być użyty dwukrotnie, jak w przypadku dwóch tekstów zaszyfrowanych c1 = p1⊕r i c2 = p2⊕r, osoba atakująca może obliczyć xor dwóch tekstów jawnych jako c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Oznacza to również, że zmiana wiadomości wymaga pełnego ponownego szyfrowania, jeśli oryginalna wiadomość mogła zostać uzyskana przez osobę atakującą. Wszystkie poniższe tryby szyfrowania parowego wymagają jedynie operacji szyfrowania szyfru blokowego, więc w zależności od szyfru może to zaoszczędzić trochę miejsca (silikonu lub kodu maszynowego) w bardzo ograniczonym środowisku.
  • CTR jest prosty, tworzy pseudolosowy strumień, który jest niezależny od tekstu jawnego, różne pseudolosowe strumienie są uzyskiwane przez zliczanie z różnych wartości nonces / IV, które są mnożone przez maksymalną długość wiadomości, aby zapobiec nakładaniu się, przy użyciu szyfrowania wiadomości nonces możliwe bez losowości na komunikat, deszyfrowanie i szyfrowanie są zakończone równolegle, błędy transmisji wpływają tylko na błędne bity i nic więcej
  • OFB tworzy również pseudolosowy strumień niezależny od tekstu jawnego, różne strumienie pseudolosowe uzyskuje się, rozpoczynając od innej wartości jednorazowej lub losowej IV dla każdej wiadomości, ani szyfrowanie, ani deszyfrowanie nie jest równoległe, ponieważ w przypadku CTR przy użyciu nonces szyfrowanie wiadomości jest możliwe bez wiadomości losowość, podobnie jak w przypadku błędów transmisji CTR, wpływają tylko na błędne bity i nic więcej
  • Pseudolosowy strumień CFB zależy od tekstu jawnego, dla każdej wiadomości potrzebna jest inna wartość jednorazowa lub losowa IV, podobnie jak w przypadku CTR i OFB użycie szyfrowania wiadomości nonces jest możliwe bez losowości poszczególnych wiadomości, deszyfrowanie jest równoległe / szyfrowanie nie jest, błędy transmisji całkowicie zniszczyć następny blok, ale wpływają tylko na nieprawidłowe bity w bieżącym bloku
• Tryby szyfrowania dysku : Tryby te specjalizują się w szyfrowaniu danych poniżej abstrakcji systemu plików. Ze względu na wydajność zmiana niektórych danych na dysku musi wymagać przepisania co najwyżej jednego bloku dysku (512 bajtów lub 4 kB). Są poza zakresem tej odpowiedzi, ponieważ mają znacznie inne scenariusze użytkowania niż inne. Nie używaj ich do niczego poza szyfrowaniem płyt na poziomie bloków . Niektórzy członkowie: XEX, XTS, LRW.

Uwierzytelnione szyfrowanie:

Aby zapobiec atakom typu padding oracle i zmianom w tekście zaszyfrowanym, można obliczyć kod uwierzytelniający wiadomość (MAC) na tekście zaszyfrowanym i odszyfrować go tylko wtedy, gdy nie został zmieniony. Nazywa się to szyfrowaniem, a następnie mac i powinno być preferowane w stosunku do dowolnej innej kolejności . Z wyjątkiem bardzo niewielu przypadków użycia autentyczność jest równie ważna jak poufność (ta ostatnia jest celem szyfrowania). Schematy szyfrowania uwierzytelnionego (z powiązanymi danymi (AEAD)) łączą dwuczęściowy proces szyfrowania i uwierzytelniania w jeden tryb szyfrowania blokowego, który również wytwarza znacznik uwierzytelniania w tym procesie. W większości przypadków powoduje to poprawę prędkości.

• CCM to prosta kombinacja trybu CTR i CBC-MAC. Używanie dwóch szyfrów szyfrów blokowych na blok jest bardzo wolne.
• OCB jest szybszy, ale obciążony patentami. Jednak dla darmowego (jak w wolności) lub niewojskowego oprogramowania posiadacz patentu udzielił bezpłatnej licencji .
• GCM jest bardzo szybką, ale prawdopodobnie złożoną kombinacją trybu CTR i GHASH, MAC ponad polem Galois z 2 ^ 128 elementami. Jego szerokie zastosowanie w ważnych standardach sieciowych, takich jak TLS 1.2, znajduje odzwierciedlenie w specjalnej instrukcji, którą Intel wprowadził w celu przyspieszenia obliczeń GHASH.

Rekomendacje:

Biorąc pod uwagę znaczenie uwierzytelnienia, polecam następujące dwa tryby szyfrowania blokowego dla większości przypadków użycia (z wyjątkiem celów szyfrowania dysku): Jeśli dane są uwierzytelniane przez podpis asymetryczny, użyj CBC, w przeciwnym razie użyj GCM.

Formalna analiza została przeprowadzona przez Phila Rogaway'a w 2011 roku tutaj . Sekcja 1.6 zawiera podsumowanie, które tutaj transkrybuję, dodając pogrubiony nacisk (jeśli jesteś niecierpliwy, to jego zaleceniem jest użycie trybu CTR, ale sugeruję przeczytanie moich akapitów na temat integralności wiadomości kontra szyfrowania poniżej).

Zauważ, że większość z nich wymaga losowości IV, co oznacza nieprzewidywalność i dlatego powinno być generowane z bezpieczeństwem kryptograficznym. Jednak niektóre wymagają tylko „nonce”, który nie wymaga tej właściwości, ale zamiast tego wymaga tylko, aby nie była ponownie wykorzystywana. Dlatego projekty, które opierają się na nonce, są mniej podatne na błędy niż projekty, które tego nie robią (i wierzcie mi, widziałem wiele przypadków, w których CBC nie jest zaimplementowane z odpowiednim wyborem IV). Zobaczysz więc, że dodałem pogrubienie, gdy Rogaway mówi coś takiego: „poufność nie jest osiągana, gdy IV jest nonce”, oznacza to, że jeśli wybierzesz swoje IV bezpieczne kryptograficznie (nieprzewidywalne), to nie ma problemu. Ale jeśli tego nie zrobisz, tracisz dobre właściwości bezpieczeństwa. Nigdy nie używaj ponownie IV w żadnym z tych trybów.

Ważne jest również zrozumienie różnicy między integralnością wiadomości a szyfrowaniem. Szyfrowanie ukrywa dane, ale osoba atakująca może zmodyfikować zaszyfrowane dane, a wyniki mogą zostać zaakceptowane przez oprogramowanie, jeśli nie sprawdzisz integralności wiadomości. Podczas gdy programista powie „ale zmodyfikowane dane wrócą jako śmieci po odszyfrowaniu”, dobry inżynier bezpieczeństwa odkryje prawdopodobieństwo, że śmieci spowodują niepożądane zachowanie w oprogramowaniu, a następnie przekształci tę analizę w prawdziwy atak. Widziałem wiele przypadków, w których zastosowano szyfrowanie, ale integralność wiadomości była naprawdę potrzebna bardziej niż szyfrowanie. Zrozum, czego potrzebujesz.

Powinienem powiedzieć, że chociaż GCM ma zarówno szyfrowanie, jak i integralność wiadomości, jest to bardzo delikatna konstrukcja: jeśli ponownie użyjesz IV, to wkręcisz się - atakujący może odzyskać twój klucz. Inne projekty są mniej delikatne, więc osobiście boję się polecić GCM w oparciu o ilość słabego kodu szyfrującego, który widziałem w praktyce.

Jeśli potrzebujesz zarówno integralności wiadomości, jak i szyfrowania, możesz połączyć dwa algorytmy: zwykle widzimy CBC z HMAC, ale nie ma powodu, aby wiązać się z CBC. Ważne jest, aby wiedzieć, najpierw zaszyfruj, a następnie MAC zaszyfrowaną zawartość , a nie na odwrót. Ponadto IV musi być częścią obliczeń MAC.

Nie znam problemów z IP.

A teraz dobre rzeczy profesora Rogaway'a:

Blokuj tryby szyfrów, szyfrowanie, ale nie integralność wiadomości

ECB : Blockcipher, tryb szyfruje wiadomości będące wielokrotnością n bitów, osobno szyfrując każdy n-bitowy kawałek. Właściwości bezpieczeństwa są słabe , metoda przecieka równość bloków w obu pozycjach bloku i czasie. Ma znaczną starszą wartość i ma wartość jako element składowy innych schematów, ale tryb nie osiąga żadnego ogólnie pożądanego celu bezpieczeństwa sam w sobie i należy go używać ze znaczną ostrożnością; EBC nie powinien być traktowany jako tryb poufności „ogólnego zastosowania” .

CBC : schemat szyfrowania oparty na IV, tryb jest bezpieczny jako probabilistyczny schemat szyfrowania, osiągając nie do odróżnienia od losowych bitów, zakładając losowy IV. Poufność nie jest osiągana, jeśli IV jest jedynie nonce , lub jeśli jest nonce zaszyfrowane pod tym samym kluczem, którego używa schemat, jak błędnie sugeruje to standard. Teksty zaszyfrowane są bardzo plastyczne. Brak wybranych zabezpieczeń przed atakiem zaszyfrowanym tekstem (CCA). Poufność przepada w przypadku wyroczni poprawnego wypełniania dla wielu metod wypełniania. Szyfrowanie nieefektywne, ponieważ jest z natury szeregowe. Powszechnie używane, właściwości bezpieczeństwa trybu prywatności tylko powodują częste niewłaściwe użycie. Może być stosowany jako element składowy algorytmów CBC-MAC. Nie mogę zidentyfikować żadnych istotnych zalet w porównaniu z trybem CTR.

CFB : schemat szyfrowania oparty na IV, tryb jest bezpieczny jako probabilistyczny schemat szyfrowania, osiągając nie do odróżnienia od losowych bitów, zakładając losowy IV. Poufność nie jest osiągana, jeśli IV jest przewidywalny , ani jeśli nie jest dokonywany przez nonce zaszyfrowane pod tym samym kluczem używanym przez system, co norma sugeruje, aby to zrobić. Teksty zaszyfrowane są ciągliwe. Brak zabezpieczeń CCA. Szyfrowanie nieefektywne, ponieważ jest z natury szeregowe. Schemat zależy od parametru s, 1 ≤ s ≤ n, zwykle s = 1 lub s = 8. Nie wystarczy, aby jedno wywołanie blockcipher mogło przetwarzać tylko bity. Tryb osiąga interesującą właściwość „samosynchronizacji”; wstawienie lub usunięcie dowolnej liczby s-bitowych znaków w tekście zaszyfrowanym tylko tymczasowo zakłóca prawidłowe odszyfrowanie.

OFB : tryb szyfrowania oparty na IV, tryb jest bezpieczny jako probabilistyczny schemat szyfrowania, osiągając nie do odróżnienia od losowych bitów, zakładając losowy IV. Poufność nie jest osiągana, jeśli IV jest nonce, chociaż ustalona sekwencja IV (np. Licznik) działa dobrze. Teksty zaszyfrowane są bardzo plastyczne. Brak bezpieczeństwa CCA. Szyfrowanie i deszyfrowanie jest nieefektywne, ponieważ jest z natury szeregowy. Natywnie szyfruje ciągi o dowolnej długości (nie wymaga wypełniania). Nie mogę zidentyfikować żadnych istotnych zalet w porównaniu z trybem CTR.

CTR : schemat szyfrowania oparty na IV, tryb osiąga nie do odróżnienia od losowych bitów przy założeniu nonce IV. Jako bezpieczny schemat nonce, tryb może być również używany jako schemat szyfrowania probabilistycznego z losowym IV. Całkowity brak prywatności, jeśli kod jednorazowy zostanie ponownie wykorzystany do szyfrowania lub deszyfrowania. Paralelność trybu często sprawia, że ​​jest on szybszy, w niektórych ustawieniach znacznie szybszy, niż inne tryby poufności. Ważny element składowy schematów szyfrowania uwierzytelnionego. Ogólnie rzecz biorąc, zwykle najlepszy i najnowocześniejszy sposób na uzyskanie szyfrowania opartego tylko na prywatności.

XTS : tryb szyfrowania oparty na IV, tryb działa poprzez zastosowanie modyfikowalnego bloku blokującego (bezpieczny jako silny PRP) do każdego n-bitowego fragmentu. W przypadku wiadomości o długości niepodzielnej przez n dwa ostatnie bloki są traktowane specjalnie. Jedynym dozwolonym zastosowaniem tego trybu jest szyfrowanie danych na blokowym urządzeniu magazynującym. Wąska szerokość leżącego u podstaw PRP i złe traktowanie ułamkowych bloków końcowych stanowią problemy. Byłby bardziej wydajny, ale mniej pożądany niż (blok blokujący) PRP-bezpieczny.

MAC (integralność wiadomości, ale nie szyfrowanie)

ALG1–6 : Zbiór adresów MAC, wszystkie oparte na CBC-MAC. Za dużo schematów. Niektóre są możliwe do udowodnienia jako VIL PRF, niektóre jako FIL PRF, a niektóre nie mają żadnego możliwego do udowodnienia bezpieczeństwa. Niektóre programy dopuszczają szkodliwe ataki. Niektóre tryby są datowane. W trybach, które go mają, niedostatecznie przestrzegana jest separacja klawiszy. Nie powinny być przyjmowane masowo, ale możliwe jest wybiórcze wybranie „najlepszych” systemów. Byłoby również w porządku przyjęcie żadnego z tych trybów na korzyść CMAC. Niektóre MAC ISO 9797-1 są szeroko znormalizowane i stosowane, szczególnie w bankowości. Zmieniona wersja normy (ISO / IEC FDIS 9797-1: 2010) wkrótce zostanie wydana [93].

CMAC : MAC oparty na CBC-MAC, tryb jest pewnie bezpieczny (aż do daty urodzin) jako PRF (VIL) (zakładając, że leżący u podstaw blockcipher jest dobrym PRP). Zasadniczo minimalny narzut dla schematu opartego na CBCMAC. Z natury szeregowy problem występujący w niektórych domenach aplikacji, a korzystanie z 64-bitowego programu blokującego wymagałoby sporadycznego ponownego kluczowania. Czystszy niż kolekcja MAC 9797-1.

HMAC : MAC oparty na funkcji skrótu kryptograficznego, a nie na blockcipher (chociaż większość funkcji skrótu kryptograficznego jest oparta na blockcipherach). Mechanizm ma silne granice bezpieczeństwa do udowodnienia, choć nie z preferowanych założeń. Wiele ściśle powiązanych wariantów w literaturze komplikuje zrozumienie tego, co jest znane. Nigdy nie sugerowano szkodliwych ataków. Szeroko znormalizowany i używany.

GMAC : MAC oparty na nonce, który jest specjalnym przypadkiem GCM. Dziedziczy wiele dobrych i złych cech GCM. Ale niepotrzebny wymóg jest niepotrzebny dla MAC, a tutaj przynosi niewielką korzyść. Praktyczne ataki, jeśli tagi są obcinane do ≤ 64 bitów, a zakres deszyfrowania nie jest monitorowany i ograniczany. Całkowity błąd przy jednorazowym użyciu. W każdym razie użycie jest niejawne, jeśli GCM zostanie przyjęty. Niezalecane do oddzielnej standaryzacji.

uwierzytelnione szyfrowanie (zarówno szyfrowanie, jak i integralność wiadomości)

CCM : nieoparty na schemacie AEAD, który łączy szyfrowanie w trybie CTR i surowy CBC-MAC. Z natury szeregowy, ograniczający prędkość w niektórych kontekstach. Pewnie bezpieczny, z dobrymi granicami, przy założeniu, że bazowy blockcipher jest dobrym PRP. Nieudolna konstrukcja, która w oczywisty sposób spełnia swoje zadanie. Łatwiejszy do wdrożenia niż GCM. Może być używany jako MAC nieoparty na jednostkach. Szeroko znormalizowany i używany.

GCM : Nieoparty na schemacie AEAD, który łączy szyfrowanie w trybie CTR i uniwersalną funkcję skrótu opartą na GF (2128). Dobra charakterystyka wydajności dla niektórych środowisk wdrożeniowych. Dobre, możliwe do udowodnienia, wyniki przy minimalnym skracaniu znaczników. Ataki i słabe granice bezpieczeństwa do udowodnienia w obecności znacznego obcięcia tagu. Może być używany jako nieoparty na MACach, który następnie nazywa się GMAC. Wątpliwy wybór, aby zezwolić na jednostki inne niż 96 bitów. Zalecamy ograniczenie wartości jednorazowych do 96 bitów i znaczników do co najmniej 96 bitów. Szeroko znormalizowany i używany.

1. Wszystko oprócz EBC.
2. Jeśli używasz CTR, konieczne jest użycie innej IV dla każdej wiadomości, w przeciwnym razie atakujący będzie w stanie pobrać dwa zaszyfrowane teksty i uzyskać połączony niezaszyfrowany zwykły tekst. Powodem jest to, że tryb CTR zasadniczo zamienia szyfr blokowy w szyfr strumieniowy, a pierwszą zasadą szyfrów strumieniowych jest to, aby nigdy nie używać dwukrotnie tego samego klucza + IV.
3. Naprawdę nie ma dużej różnicy w tym, jak trudne są tryby do wdrożenia. Niektóre tryby wymagają tylko szyfru blokowego do działania w kierunku szyfrowania. Jednak większość szyfrów blokowych, w tym AES, nie wymaga znacznie więcej kodu do wdrożenia deszyfrowania.
4. Dla wszystkich trybów szyfrowania ważne jest stosowanie różnych IV dla każdej wiadomości, jeśli twoje wiadomości mogą być identyczne w pierwszych kilku bajtach, a nie chcesz, aby atakujący to wiedział.

Czy zacząłeś od przeczytania informacji na ten temat na Wikipedii - Blokowanie trybów szyfrowania ? Następnie kliknij link referencyjny w Wikipedii do NIST: Zalecenie dotyczące blokowych trybów szyfru operacji .

Możesz wybrać na podstawie tego, co jest powszechnie dostępne. Miałem to samo pytanie i oto wyniki moich ograniczonych badań.

Ograniczenia sprzętowe

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

Ograniczenia otwartego źródła

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

Znam jeden aspekt: ​​chociaż CBC zapewnia lepsze bezpieczeństwo poprzez zmianę IV dla każdego bloku, nie dotyczy to przypadkowo zaszyfrowanej treści (jak zaszyfrowany dysk twardy).

Tak więc użyj CBC (i innych trybów sekwencyjnych) dla strumieni sekwencyjnych i EBC dla losowego dostępu.