Słowo wstępu: ta odpowiedź była po części odpowiedzią na wiele pytań, które widziałem pod tagiem [encryption], które pokazywały, że ludzie wdrażają całkowicie niezabezpieczony kod. Zwracając się do tych programistów napisałem następujące zdanie otwierające z zamiarem wstrząśnięcia nimi na tyle, aby przemyśleć ich podejście do kryptografii, zanim ich aplikacja zostanie zaatakowana. Jeśli jesteś tutaj w procesie uczenia się, to świetnie! Potrzebujemy więcej programistów z wiedzą w zakresie kryptografia. Pytaj dalej i dodaj ciche " jeszcze!"do mojego otwarcia:

Jeśli musisz zadać to pytanie, prawdopodobnie nie wiesz wystarczająco dużo o kryptografii, aby wdrożyć bezpieczny system.

Wiem, że brzmi to surowo, więc pozwól mi zilustrować mój punkt: wyobraź sobie, że budujesz aplikację internetową i musisz przechowywać dane sesji. Można przypisać każdemu użytkownikowi identyfikator sesji i zapisać dane sesji na serwerze w mapie hash mapowania ID sesji do danych sesji. Ale wtedy masz aby poradzić sobie z tym nieznośnym stanem na serwerze i jeśli w pewnym momencie Potrzebujesz więcej niż jednego serwera, sprawy będą się bałagan. Zamiast tego masz pomysł, aby zapisać dane sesji w pliku cookie po stronie klienta. Oczywiście zaszyfrujesz je, aby użytkownik nie mógł odczytać i manipulować danymi. Więc jakiego trybu należy użyć? Przychodząc tutaj czytasz najlepszą odpowiedź (przepraszam za wyróżnienie Ciebie myforwik). Pierwszy z nich-ECB-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 losowego dostępu, więc nie ma XTS i patentów to PITA, więc nie ma OCB. Korzystając z biblioteki kryptograficznej zdajesz sobie sprawę, że potrzebujesz wypełnienia, ponieważ możesz szyfrować tylko wielokrotności rozmiaru bloku. Wybierasz PKCS7, ponieważ został zdefiniowany w niektórych poważnych standardach kryptograficznych. Po przeczytaniu gdzieś, że CBC jest provably secure jeśli jest używany z losowym IV i bezpiecznym szyfrem blokowym, odpoczywasz spokojnie, nawet jeśli jesteś przechowywanie poufnych danych po stronie klienta.

Po latach, gdy Twoja usługa rzeczywiście wzrosła do znacznych rozmiarów, Specjalista ds. bezpieczeństwa IT skontaktuje się z Tobą w odpowiedzialnym ujawnieniu. Mówi ci, że może odszyfrować wszystkie Twoje pliki cookie za pomocą ataku padding Oracle attack , ponieważ twój kod generuje stronę błędu, jeśli padding jest w jakiś sposób uszkodzony.

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

Problem polega na tym, że istnieje wiele pułapek dotyczących kryptografii i niezwykle łatwo jest zbudować system, który wygląda bezpiecznie dla laika, ale jest trywialny do złamania dla kompetentnego atakującego.

Co zrobić, jeśli trzeba zaszyfrować dane

Dla połączeń na żywo użyj TLS (sprawdź nazwę hosta certyfikatu i łańcuch wystawcy). Jeśli nie możesz korzystać z TLS, poszukaj najwyższego poziomu API, który Twój system ma do zaoferowania dla Twojego zadania i upewnij się, że zrozum, jakie gwarancje oferuje, a co ważniejsze, czego nie gwarantuje. W powyższym przykładzie framework taki jak Play oferuje obiekty pamięci po stronie klienta, nie unieważnia przechowywanych danych po pewnym czasie, a jeśli zmienisz stan po stronie klienta, atakujący może przywrócić poprzedni stan bez twojej uwagi.

Jeśli nie ma abstrakcji wysokiego poziomu, użyj biblioteki kryptograficznej wysokiego poziomu. Wybitnym przykładem jest NaCl i przenośną implementacją z wieloma powiązaniami językowymi jest . Korzystając z takiej biblioteki nie musisz dbać o tryby szyfrowania itp. ale trzeba być jeszcze bardziej ostrożnym o szczegóły użytkowania niż z wyższego poziomu abstrakcji, jak nigdy nie używając nonce dwa razy.

Jeśli z jakiegoś powodu nie możesz korzystać z biblioteki kryptograficznej wysokiego poziomu, na przykład dlatego, że musisz wchodzić w interakcje z istniejącym systemem w określony sposób, nie ma sposobu na dokładne wykształcenie się. I polecam lekturę Cryptography Engineering autorstwa Fergusona, Kohno i Schneiera. Nie oszukuj się, wierząc, że możesz zbudować bezpieczny system bez niezbędnego zaplecza. Kryptografia jest niezwykle subtelna i prawie niemożliwe jest przetestowanie bezpieczeństwa systemu.

Dla celów edukacyjnych porównanie trybów

Tylko szyfrowanie:

• tryby wymagające wypełnienia : Jak w przykładzie, padding może być na ogół niebezpieczne ponieważ otwiera to możliwość blokowania ataków oracle. Najprostszą obroną jest uwierzytelnienie każdej wiadomości przed odszyfrowaniem. Patrz poniżej.
  • EBC szyfruje każdy blok danych niezależnie i ten sam blok tekstowy spowoduje powstanie tego samego bloku tekstowego. Spójrz na zaszyfrowany obraz smokingu EBC na stronie EBC Wikipedia {[11] } aby zobaczyć, dlaczego jest to poważny problem. Nie znam żadnego przypadku użycia, w którym EBC byłby akceptowalny.
  • morfologia ma IV i dlatego potrzebuje losowości za każdym razem, gdy wiadomość jest zaszyfrowana, zmiana części wiadomości wymaga ponownego zaszyfrowania wszystkiego po zmianie, błędy transmisji w jednym bloku szyfrowym całkowicie niszczą tekst jawny i zmieniają deszyfrowanie następnego bloku, deszyfrowanie może być równoległe / szyfrowanie nie może, tekst jawny jest plastyczny do pewnego stopnia - może to być problem .
• tryby szyfru strumieniowego : tryby te generują pseudo losowy strumień danych, który może lub nie może zależeć od zwykłego tekstu. Podobnie jak w przypadku szyfrów strumieniowych, generowany pseudo strumień losowy jest Xorowany za pomocą zwykłego tekstu w celu wygenerowania szyfru. Ponieważ możesz użyć tak wielu bitów strumienia losowego, jak chcesz, nie potrzebujesz wypełnienia w ogóle. Wadą tej prostoty jest to, że szyfrowanie jest całkowicie plastyczne , co oznacza, że odszyfrowanie może być zmienione przez atakującego w dowolny sposób, jaki lubi, jak dla zwykłego tekstu p1, zaszyfrowanego C1 i pseudo-losowego strumienia R i może wybrać sytuację D w ten sposób, że transkrypcja zaszyfrowanego tekstu C2=C1⊕D wynosi P2 = P1⊕D, a N2 = C2⊕P = (C1 ⊕ q) ⊕ r = e ⊕ (C1 ⊕ P). I tym samym być przepływ nigdy nie powinny być używane dwa razy w ciągu dwóch шифртекстов C1=P1⊕p i S2=P2⊕P, osoba atakująca może obliczyć XOR z dwóch plaintexts jak C1⊕C2=P1⊕P⊕P2⊕P=P1⊕P2. Oznacza to również, że zmiana wiadomości wymaga pełnego ponownego szyfrowania, jeśli oryginalna wiadomość mogła zostać uzyskana przez napastnik. Wszystkie poniższe tryby szyfru parowego wymagają jedynie operacji szyfrowania szyfru blokowego, więc w zależności od szyfru może to zaoszczędzić trochę miejsca (kod krzemowy lub maszynowy) w skrajnie ograniczonych środowiskach.
  • CTR jest prosty, tworzy pseudo losowy strumień, który jest niezależny od zwykłego tekstu, różne pseudo losowe strumienie są uzyskiwane przez liczenie z różnych nonces / IVs, które są mnożone przez maksymalną długość wiadomości tak, że nakładają się na siebie szyfrowanie wiadomości nie jest możliwe bez przypadkowości wiadomości, odszyfrowywanie i szyfrowanie są wykonywane 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 zwykłego tekstu, różne pseudolosowe strumienie są uzyskiwane przez rozpoczęcie od innego nonce lub random IV dla każdej wiadomości, ani szyfrowanie, ani deszyfrowanie nie jest równoległe, jak w przypadku CTR za pomocą nonce szyfrowanie wiadomości jest możliwe bez przypadkowości jednej wiadomości, ponieważ błędy transmisji CTR wpływają tylko na błędne bity i nic więcej [59]}
  • Cfb 'S pseudo losowy strumień zależy od zwykłego tekstu, inny nonce lub random IV jest potrzebne dla każdej wiadomości, jak w przypadku CTR i OFB przy użyciu nonces szyfrowanie wiadomości jest możliwe bez przypadkowości na wiadomość, deszyfrowanie jest równoległe / szyfrowanie nie jest, błędy transmisji całkowicie zniszczyć następujący blok, ale tylko efekt niewłaściwych bitów w bieżącym bloku
• tryby szyfrowania dysku: tryby te są wyspecjalizowane do szyfrowania danych poniżej abstrakcji systemu plików. Ze wzglÄ ™ du na wydajnoĹ " Ä ‡ zmiana niektĂłrych danych na dysku musi wymagaÄ ‡ jedynie przepisania co najwyżej jednego bloku dysku (512 bajtăłw lub 4kib). Są poza zakresem tej odpowiedzi, ponieważ mają znacznie inne scenariusze użytkowania niż inne. Nie używaj ich do niczego poza płytą z poziomem bloku szyfrowanie . Niektórzy członkowie: XEX, XTS, LRW.

Uwierzytelnione szyfrowanie:

Aby zapobiec atakom typu padding Oracle i zmianom w tekście szyfrowym, można obliczyć kod uwierzytelniający message authentication code (MAC) na tekście szyfrowym i odszyfrować go tylko wtedy, gdy nie został naruszony. Kod ten nazywa się encrypt-then-mac i powinien być preferowany w stosunku do każdej innej kolejności. Z wyjątkiem bardzo niewielu przypadków użycia autentyczność jest równie ważna jak poufność (z których ostatni jest celu szyfrowania). Uwierzytelnione Schematy szyfrowania (z powiązanymi danymi (AEAD)) łączą dwuczęściowy proces szyfrowania i uwierzytelniania w jeden tryb szyfru blokowego, który wytwarza również znacznik uwierzytelniania w procesie. W większości przypadków powoduje to poprawę prędkości.

• CCM jest prostą kombinacją trybu CTR i CBC-MAC. Użycie dwóch szyfrów blokowych na blok jest bardzo powolne.
• OCB jest szybsze, ale obciążone patentami. Za wolne (jak w wolnoĹ "ci) lub niewojskowe oprogramowanie posiadacz patentu udzieliĺ' wolnej licencji.
• GCM jest bardzo szybką, ale prawdopodobnie złożoną kombinacją trybu CTR i GHASH, MAC nad polem Galois z elementami 2^128. Jego szerokie zastosowanie w ważnych standardach sieciowych, takich jak TLS 1.2, jest odzwierciedlone przez specjalną instrukcję Intel wprowadził, aby przyspieszyć obliczanie GHASH.

Zalecenie:

Biorąc pod uwagę znaczenie uwierzytelniania zalecałbym następujące dwa tryby szyfrowania blokowego w większości przypadków (z wyjątkiem szyfrowania dysku): jeśli dane są uwierzytelniane za pomocą podpisu asymetrycznego, użyj CBC, w przeciwnym razie użyj GCM.

1. Wszystko oprócz EBC.
2. Jeśli używasz CTR, konieczne jest użycie innego IV dla każdej wiadomości, w przeciwnym razie atakujący będzie mógł wziąć dwa szyfry i uzyskać połączony niezaszyfrowany tekst jawny. Powodem jest to, że tryb CTR zasadniczo zmienia szyfr blokowy w szyfr strumieniowy, a pierwszą zasadą szyfrów strumieniowych jest nigdy nie używać tego samego klucza+IV dwa razy.
3. naprawdę nie ma dużej różnicy w tym, jak trudne są tryby do wdrożenia. Niektóre tryby wymagaj tylko, aby szyfr blokowy działał w kierunku szyfrowania. Jednak większość szyfrów blokowych, w tym AES, nie wymaga znacznie więcej kodu, aby zaimplementować deszyfrowanie.
4. dla wszystkich trybów szyfrowania ważne jest, aby używać różnych IV dla każdej wiadomości, Jeśli wiadomości mogą być identyczne w pierwszych kilku bajtach, a nie chcesz, aby atakujący wiedział o tym.

Analiza formalna została wykonana przez Phila Rogawaya w 2011 roku, tutaj . Sekcja 1.6 daje podsumowanie, które przepisuję tutaj, dodając własne podkreślenie pogrubioną czcionką (jeśli jesteś niecierpliwy, to jego zalecenie jest użycie trybu CTR, ale sugeruję, abyś przeczytał moje akapity o integralności wiadomości kontra szyfrowanie poniżej).

Zauważ, że większość z nich wymaga, aby IV był losowy, co oznacza, że nie jest przewidywalny i dlatego powinien być generowany z zabezpieczeniem kryptograficznym. Jednak niektóre wymagają tylko "nonce", która nie wymaga tej właściwości, ale zamiast tego wymaga tylko, aby nie była ponownie używana. Dlatego projekty, które opierają się na nonce są mniej podatne na błędy niż projekty, które tego nie robią (i uwierz mi, widziałem wiele przypadków, w których CBC nie jest realizowane z odpowiednim wyborem IV). Więc zobaczysz, że dodałem pogrubienie, gdy Rogaway mówi coś w stylu "poufność nie jest osiągana, gdy IV jest nonce", oznacza to, że jeśli wybierzesz swój IV kryptograficznie Bezpieczny (nieprzewidywalny), to nie ma sprawy. Ale jeśli nie, to tracisz dobre właściwości bezpieczeństwa. Nigdy nie używaj ponownie kroplówki dla żadnego z tych trybów.

Ważne jest również, aby zrozumieć różnicę między integralnością wiadomości a szyfrowaniem. Szyfrowanie ukrywa dane, ale atakujący może być w stanie zmodyfikować zaszyfrowane dane, a wyniki mogą zostać zaakceptowane przez oprogramowanie, jeśli nie sprawdzisz integralności wiadomości. Podczas gdy deweloper powie " ale zmodyfikowane dane wrócą jako śmieci po odszyfrowaniu", dobry inżynier bezpieczeństwa znajdzie prawdopodobieństwo, że śmieci powodują niekorzystne zachowania w oprogramowaniu, a następnie zamieni tę analizę w prawdziwy atak. Widziałem wiele przypadków, w których stosowano 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, masz przerąbane -- atakujący może odzyskać klucz. Inne projekty są mniej kruche, 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 morfologię z HMAC, ale nie ma powodu, aby wiązać się z morfologią. Najważniejsze, aby wiedzieć, to najpierw Szyfruj, a następnie MAC zaszyfrowaną zawartość , a nie na odwrót. Ponadto IV musi być częścią obliczenie MAC.

Nie znam się na problemach z IP.

A teraz dobra rzecz od profesora Rogawaya:

Tryby Szyfrów blokowych, szyfrowanie, ale nie integralność wiadomości

ECB : blockcipher, tryb encyphers wiadomości, które są wielokrotnością N bitów przez osobne encyphering każdy N-bit kawałek. właściwości zabezpieczeń są słabe , metoda ta pozwala na równość bloków w obu pozycjach bloku i w czasie. O znacznej wartości, a także wartości jako element konstrukcyjny dla innych systemów, ale tryb ten sam w sobie nie osiąga żadnego ogólnie pożądanego celu w zakresie bezpieczeństwa i musi być stosowany ze znaczną ostrożnością; EBC nie powinien być traktowany jako tryb poufności" ogólnego przeznaczenia " .

CBC: schemat szyfrowania oparty na IV, tryb jest Bezpieczny jako probabilistyczny schemat szyfrowania, osiągając nieodróżnialność od losowych bitów, zakładając losowe IV. poufność nie jest osiągana, jeśli IV jest tylko nonce , ani jeśli nie jest to nonce zakodowane pod tym samym kluczem używanym przez schemat, co standard błędnie sugeruje. Szyfertexty są bardzo plastyczne. Brak wybranych zabezpieczeń przed atakami za pomocą szyfrowania (CCA). Poufność przepada w obecności poprawnej oracle-padding dla wielu metod padding. Szyfrowanie nieefektywne od bycia z natury szeregowym. Powszechnie stosowane właściwości zabezpieczeń trybu prywatności powodują częste nadużycia. Może być używany jako budulec dla algorytmów CBC-MAC. nie mogę zidentyfikować żadnej ważnej przewagi nad trybem CTR.

CFB : schemat szyfrowania oparty na IV, tryb jest Bezpieczny jako probabilistyczny schemat szyfrowania, osiągając nieodróżnialność od losowych bitów, zakładając losowe IV. poufność nie jest osiągana, jeśli IV jest przewidywalny , ani jeśli nie jest wykonany przez niecyfrowy klucz używany przez schemat, co standard błędnie sugeruje. Szyfertexty są plastyczne. Brak ochrony CCA. Szyfrowanie nieefektywne od bycia z natury seryjnym. Schemat zależy od parametru s, 1 ≤ s ≤ n, zazwyczaj s = 1 lub S = 8. Nieefektywne, ponieważ wymaga jednego wywołania blockcipher, aby przetwarzać tylko bity s . Tryb osiąga interesującą właściwość "autosynchronizacji"; wstawianie lub usuwanie dowolnej liczby znaków s-bitowych do szyfrogramu tylko tymczasowo zakłóca prawidłowe odszyfrowanie.

OFB : schemat szyfrowania oparty na IV, tryb jest Bezpieczny jako probabilistyczny schemat szyfrowania, osiągając nieodróżnialność od losowych bitów, przy założeniu losowego IV. nie osiąga się, jeśli IV jest nonce, chociaż stała Sekwencja IVs (np. licznik) działa dobrze. Szyfertexty są bardzo plastyczne. Brak ochrony CCA. Szyfrowanie i deszyfrowanie nieefektywne od bycia z natury szeregowym. Natywnie szyfruje ciągi o dowolnej długości bitów(bez wypełnienia). Nie mogę zidentyfikować żadnych ważnych zalet w stosunku do trybu CTR.

CTR : schemat szyfrowania oparty na IV, tryb osiąga nie do odróżnienia od losowych bitów zakładając, że nonce IV. jako bezpieczny schemat oparty na nonce, tryb może być również używany jako probabilistyczny schemat szyfrowania, z random IV. całkowita awaria prywatności, jeśli nonce zostanie ponownie użyty podczas szyfrowania lub deszyfrowania. Równoległość trybu często sprawia, że jest on szybszy, w niektórych ustawieniach znacznie szybciej, niż w innych trybach poufności. Ważny element składowy uwierzytelnionych schematów szyfrowania. ogólnie, zwykle najlepszy i najnowocześniejszy sposób na osiągnij szyfrowanie tylko dla prywatności.

XTS : schemat szyfrowania oparty na IV, tryb działa poprzez zastosowanie zmodyfikowanego blockcipher (secure as a strong-PRP)do każdego n-bitowego fragmentu. Dla wiadomości o długościach nie podzielnych przez n, dwa ostatnie bloki są traktowane specjalnie. Jedynym dozwolonym użyciem tego trybu jest szyfrowanie danych na urządzeniu pamięci masowej o strukturze blokowej. Wąska szerokość podstawowego PRP i słabe traktowanie ułamkowych bloków końcowych to problemy. Bardziej wydajny, ale mniej pożądane niż (szeroki blok) PRP-secure blockcipher byłoby.

ALG1-6: kolekcja komputerów Mac, wszystkie oparte na CBC-MAC. Zbyt wiele intryg. Niektóre są udowodnione jako Vil PRFs, niektóre jako FIL PRFs, a niektóre nie mają udowodnionego bezpieczeństwa. Niektóre programy przyznają się do szkodliwych ataków. Niektóre tryby są datowane. Separacja kluczy jest niewystarczająca dla trybów, które ją posiadają. Nie powinny być przyjmowane masowo, ale selektywny wybór "najlepszych" schematów jest możliwy. Byłoby również w porządku, aby przyjąć żaden z tych trybów, na rzecz CMAC. Niektóre Maki ISO 9797-1 są szeroko znormalizowane i stosowane, zwłaszcza w bankowości. Poprawiona wersja standardu (ISO / IEC FDIS 9797-1:2010) zostanie wkrótce wydana [93].

CMAC : MAC oparty na CBC-MAC, tryb jest provably bezpieczny (do daty urodzin) jako (VIL) PRF (zakładając, że bazowy blockcipher jest dobrym PRP). Zasadniczo Minimalne napowietrzne dla systemu opartego na CBCMAC. Z natury szeregowy problem w niektórych domenach aplikacji, a użycie 64-bitowego blockciphera wymagałoby sporadycznego ponownego wprowadzania kluczy. Czystsze niż kolekcja komputerów Mac ISO 9797-1.

HMAC : MAC oparty na kryptograficznej funkcji skrótu, a nie blockcipher (chociaż większość kryptograficznych funkcji skrótu opiera się na blockcipherach). Mechanizm ma silne, udowodnione granice bezpieczeństwa, choć nie z preferowanych założeń. Wiele blisko spokrewnionych wariantów w literaturze komplikuje zrozumienie tego, co znane. Nigdy nie sugerowano żadnych szkodliwych ataków. Szeroko znormalizowane i stosowane.

GMAC : Mac oparty na niece, który jest szczególnym przypadkiem GCM. Dziedziczy wiele dobrych i złych cech GCM. Ale nonce-wymóg jest niepotrzebny dla Maca, a tutaj kupuje niewiele korzyści. Praktyczne ataki, jeśli znaczniki są obcięte do ≤ 64 bitów, a zakres odszyfrowywania nie jest monitorowany i skrępowany. Całkowita awaria przy braku ponownego użycia. Użycie i tak jest niejawne, jeśli przyjęto GCM. Nie zaleca się oddzielnej standaryzacji.

CCM : schemat AEAD oparty na niece, który łączy szyfrowanie w trybie CTR i surowy MORFOLOGIA-MAC. Z natury szeregowy, ograniczający prędkość w niektórych kontekstach. Provably secure, with good bounds, zakładając, że bazowy blockcipher jest dobrym PRP. Bezbożna konstrukcja, która wyraźnie robi swoje. Prostsze do wdrożenia niż GCM. Może być używany jako MAC oparty na niece. Szeroko znormalizowane i stosowane.

GCM: schemat AEAD oparty na niece, który łączy szyfrowanie w trybie CTR i uniwersalną funkcję skrótu opartą na GF(2128). Dobre charakterystyki wydajności dla niektórych środowisk implementacyjnych. Dobre wyniki przy minimalnym obcinaniu znaczników. Ataki i słabe, udowodnione granice bezpieczeństwa w obecności znacznego obcinania znaczników. Może być używany jako Mac oparty na niece, który następnie nazywa się GMAC. Wątpliwy wybór pozwalający na niecki inne niż 96-bitowe. Zaleca się ograniczenie nonces do 96 bitów i znaczników do co najmniej 96 bitów. Szeroko znormalizowane i stosowane.

Czy zacząłeś od przeczytania informacji na ten temat na Wikipedii - tryby działania szyfru blokowego? Następnie przejdź do odnośnika na Wikipedii Do NIST: zalecenie dla trybów działania Szyfrów blokowych .

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 Open source

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 daje lepsze bezpieczeństwo, zmieniając IV dla każdego bloku, nie ma zastosowania do losowo dostępnych zaszyfrowanych treści (jak zaszyfrowany dysk twardy).

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