어떤 상황에서 어떤 것이 선호됩니까?

다양한 모드의 평가 기준 목록과 각 기준의 적용 가능성에 대한 토론을보고 싶습니다.

예를 들어, 기준 중 하나는 암호화 및 암호 해독에 대한 "코드 크기"이며, 이는 802.11 네트워크 어댑터와 같은 마이크로 코드 임베디드 시스템에 중요합니다. CBC를 구현하는 데 필요한 코드가 CTR에 필요한 코드보다 훨씬 작은 경우 (이것이 사실인지 모르겠지만, 단지 예일뿐입니다) 작은 코드를 사용하는 모드가 선호되는 이유를 이해할 수 있습니다. 그러나 서버에서 실행되는 앱을 작성하고 있으며 사용중인 AES 라이브러리가 CBC와 CTR을 모두 구현하는 경우이 기준은 관련이 없습니다.

"평가 기준 목록 및 각 기준의 적용 가능성"이 의미하는 바를 확인하십시오.

이것은 실제로 프로그래밍과 관련이 없지만 알고리즘과 관련이 있습니다.

• 동일한 키로 둘 이상의 데이터 블록을 암호화하는 경우 ECB를 사용하지 않아야합니다.

• CBC, OFB 및 CFB는 비슷하지만 OFB / CFB는 암호 공간 만 절약 할 수있는 암호 해독 만 필요하기 때문에 더 좋습니다.

• CBC / OFB / CFB 대신 병렬화 (예 : 속도)를 원할 경우 CTR이 사용됩니다.

• XTS 모드는 하드 디스크 또는 RAM과 같은 임의의 액세스 가능한 데이터를 인코딩하는 경우 가장 일반적입니다.

• OCB는 단일 패스에서 암호화 및 인증을 허용하므로 가장 좋은 모드입니다. 그러나 미국에는 특허가 있습니다.

실제로 알아야 할 것은 1 블록 만 암호화하지 않는 한 ECB를 사용하지 않아야한다는 것입니다. 스트림이 아닌 임의로 액세스 한 데이터를 암호화하는 경우 XTS를 사용해야합니다.

• 암호화 할 때마다 항상 고유 한 IV 를 사용해야하며 무작위로 사용해야합니다 . 그것들이 무작위 임을 보장 할 수 없다면 , OCB 는 IV가 아닌 nonce 만 필요 하고 뚜렷한 차이가 있으므로 OCB를 사용하십시오 . 넌스은 사람들이 다음을 추측 할 경우, 보안을 드롭하지 않습니다 IV는 이 문제가 발생할 수 있습니다.

자체 암호화를 구현할 수 없다면 길고 열심히 고려하십시오.

문제의 추악한 사실은이 질문을하면 보안 시스템을 설계하고 구현할 수 없다는 것입니다.

요점을 설명해 드리겠습니다. 웹 응용 프로그램을 구축 중이고 일부 세션 데이터를 저장해야한다고 상상해보십시오. 각 사용자에게 세션 ID를 할당하고 세션 데이터에 대한 해시 맵 매핑 세션 ID로 서버의 세션 데이터를 저장할 수 있습니다. 그러나 서버 에서이 성가신 상태를 처리해야하며 어느 시점에서 하나 이상의 서버가 필요한 경우 일이 지저분 해집니다. 따라서 클라이언트 측의 쿠키에 세션 데이터를 저장하는 아이디어가 있습니다. 물론 사용자가 데이터를 읽고 조작 할 수 없도록 암호화합니다. 어떤 모드를 사용해야합니까? 여기에 오면 당신은 최고 답변을 읽습니다 (myforwik을 불러서 죄송합니다). 첫 번째로 설명 된 ECB는 귀하를위한 것이 아니며, 하나 이상의 블록을 암호화하려고합니다. 다음 블록은 CBC처럼 들리며 CTR의 병렬 처리가 필요하지 않으며, 임의 액세스가 필요하지 않습니다. 따라서 XTS와 특허는 PITA가 아니므로 OCB도 없습니다. 암호화 라이브러리를 사용하면 블록 크기의 배수 만 암호화 할 수 있기 때문에 약간의 패딩이 필요하다는 것을 알게됩니다. 당신은 선택PKCS7 은 일부 심각한 암호화 표준에 정의되어 있기 때문입니다. 임의 IV 및 보안 블록 암호와 함께 사용하는 경우 CBC가 안전한지 어딘가에서 읽은 후에 는 클라이언트 측에 중요한 데이터를 저장하더라도 안심할 수 있습니다.

몇 년 후 서비스가 실제로 상당한 규모로 성장한 후 IT 보안 전문가가 책임있는 공개를 통해 귀하에게 연락합니다. 그녀는 패딩 오라클 공격을 사용하여 모든 쿠키를 해독 할 수 있다고 알려줍니다 . 패딩이 어떻게 든 손상된 경우 코드에서 오류 페이지가 생성되기 때문입니다.

이것은 가상의 시나리오가 아닙니다. Microsoft는 몇 년 전까지 ASP.NET에서 이러한 결함을 발견했습니다.

문제는 암호화와 관련하여 많은 함정이 있으며 일반인에게는 안전 해 보이지만 지식이 풍부한 공격자에게는 침입하기 쉬운 시스템을 구축하는 것이 매우 쉽다는 것입니다.

데이터를 암호화해야 할 경우 수행 할 작업

라이브 연결의 경우 TLS를 사용하십시오 (인증서 및 발급자 체인의 호스트 이름을 확인하십시오). TLS를 사용할 수없는 경우 시스템이 작업에 제공해야하는 최고 수준의 API를 찾고 제공되는 보증과 보증하지 않는 것을 더 잘 이해해야합니다. 위의 예에서 Play 와 같은 프레임 워크 는 클라이언트 측 스토리지 기능을 제공 하지만, 일정 시간이 지난 후에 저장된 데이터를 무효화하지 않으며, 클라이언트 측 상태를 변경 한 경우 공격자는 사용자에게 알리지 않고 이전 상태를 복원 할 수 있습니다.

사용 가능한 고급 추상화가없는 경우 고급 암호화 라이브러리를 사용하십시오. 눈에 띄는 예는 NaCl 이며 많은 언어 바인딩을 가진 이식 가능한 구현은 Sodium 입니다. 이러한 라이브러리를 사용하면 암호화 모드 등을 신경 쓸 필요가 없지만 nonce를 두 번 사용하지 않는 것과 같이 높은 수준의 추상화보다 사용 세부 사항에 대해 더주의해야합니다.

예를 들어 특정 방식으로 기존 시스템과 상호 작용해야하기 때문에 높은 수준의 암호화 라이브러리를 사용할 수없는 경우 철저한 교육을받을 방법이 없습니다. Ferguson, Kohno 및 Schneier의 Cryptography Engineering을 읽는 것이 좋습니다 . 필요한 배경없이 안전한 시스템을 구축 할 수 있다고 믿지 마십시오. 암호화는 매우 미묘하며 시스템의 보안을 테스트하는 것은 거의 불가능합니다.

모드 비교

암호화 만 :

• 패딩이 필요한 모드 : 예제 에서처럼 패딩은 일반적으로 패딩 오라클 공격의 가능성을 열어 주므로 위험 할 수 있습니다. 가장 쉬운 방어 방법은 해독 전에 모든 메시지를 인증하는 것입니다. 아래를 참조하십시오.
  • ECB는 각 데이터 블록을 독립적으로 암호화하며 동일한 평문 블록은 동일한 암호문 블록을 생성합니다. ECB Wikipedia 페이지 에서 ECB 암호화 Tux 이미지 를보고 이것이 왜 심각한 문제인지 확인하십시오. ECB를 수용 할 수있는 유스 케이스를 모르겠습니다.
  • CBC 에는 IV가 있으므로 메시지가 암호화 될 때마다 임의성이 필요합니다. 메시지의 일부를 변경하면 변경 후 모든 것을 다시 암호화해야합니다. 한 암호문 블록의 전송 오류는 일반 텍스트를 완전히 파괴하고 다음 블록의 암호 해독을 변경합니다. 병렬화 / 암호화는 불가능하며, 평문은 어느 정도 전성 입니다. 이것은 문제가 될 수 있습니다 .
• 스트림 암호 모드 :이 모드는 평문에 의존하거나 그렇지 않은 의사 랜덤 데이터 스트림을 생성합니다. 스트림 암호와 유사하게, 생성 된 의사 랜덤 스트림은 암호문을 생성하기 위해 평문과 XOR된다. 원하는만큼 많은 수의 랜덤 스트림을 사용할 수 있으므로 패딩이 전혀 필요하지 않습니다. 이 단순성의 단점은 암호화가 완전히 변형 가능 하다는 것입니다즉, 일반 텍스트 p1, 암호 텍스트 c1 및 의사 랜덤 스트림 r에서와 같이 원하는 방식으로 암호 해독을 변경할 수 있으며 공격자는 암호 텍스트 c2 = c1⊕d와 같이 차이 d를 선택할 수 있습니다. p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r)와 같이 p2 = p1⊕d입니다. 또한 동일한 의사 랜덤 스트림은 두 개의 암호문 c1 = p1⊕r과 c2 = p2⊕r에 대해 두 번 사용해서는 안되며, 공격자는 두 개의 평문의 xor를 c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. 즉, 공격자가 원본 메시지를 얻을 수있는 경우 메시지를 변경하려면 완전한 재 암호화가 필요합니다. 다음의 모든 증기 암호 모드는 블록 암호의 암호화 작업 만 필요하므로 암호에 따라 매우 제한된 환경에서 일부 (실리콘 또는 기계 코드) 공간을 절약 할 수 있습니다.
  • CTR 은 단순하고 일반 텍스트와 독립적 인 의사 랜덤 스트림을 생성하며, 최대 메시지 길이를 곱한 서로 다른 nonces / IV에서 카운트하여 다른 의사 랜덤 스트림을 얻습니다. 메시지 당 임의성없이 가능, 해독 및 암호화가 병렬화 가능하며 전송 오류는 잘못된 비트에만 영향을 미치며 더 이상 아무것도 아닙니다.
  • OFB 는 또한 일반 텍스트와 독립적 인 의사 랜덤 스트림을 생성하며, 모든 메시지에 대해 다른 nonce 또는 random IV로 시작하여 다른 의사 랜덤 스트림을 얻습니다. CTR 전송 오류와 마찬가지로 무작위성은 잘못된 비트에만 영향을 미치며 더 이상 아무것도 아닙니다.
  • CFB 의 의사 랜덤 스트림은 평문에 의존하며, 모든 메시지마다 다른 nonce 또는 random IV가 필요합니다 .CTR 및 OFB와 같이 nonces 메시지 암호화를 사용하는 메시지 랜덤은 메시지 랜덤 성이없이 가능하며, 해독은 병렬화 가능 / 암호화는 불가능합니다 다음 블록을 파괴하지만 현재 블록의 잘못된 비트에만 영향을 미칩니다.
• 디스크 암호화 모드 :이 모드는 파일 시스템 추상화 아래의 데이터를 암호화하는 데 특화되어 있습니다. 효율성상의 이유로 디스크의 일부 데이터를 변경하면 최대 하나의 디스크 블록 (512 바이트 또는 4kib) 만 다시 쓰면됩니다. 그들은 다른 사용법 시나리오와는 크게 다른 시나리오를 가지고 있기 때문에이 답변의 범위를 벗어났습니다. 블록 레벨 디스크 암호화 이외의 용도로는 사용하지 마십시오 . 일부 회원 : XEX, XTS, LRW.

인증 된 암호화 :

패딩 오라클 공격 및 암호문의 변경을 방지하기 위해 암호문에 대한 메시지 인증 코드 (MAC)를 계산하고 변조되지 않은 경우에만 암호를 해독 할 수 있습니다. 이것을 encrypt-then-mac이라고하며 다른 순서보다 선호되어야합니다 . 극소수의 사용 사례를 제외하고는 신뢰성이 기밀성만큼 중요합니다 (후자는 암호화의 목적 임). 인증 된 암호화 체계 (관련 데이터 (AEAD)와 함께)는 암호화 및 인증의 두 부분 프로세스를 하나의 블록 암호 모드로 결합하여 프로세스에서 인증 태그를 생성합니다. 대부분의 경우 속도가 향상됩니다.

• CCM 은 CTR 모드와 CBC-MAC의 간단한 조합입니다. 블록 당 두 개의 블록 암호 암호화를 사용하면 속도가 매우 느립니다.
• OCB 는 빠르지 만 특허에 의해 방해받습니다. 그러나 무료 (무상) 또는 비 군용 소프트웨어의 경우 특허 보유자 는 무료 라이센스를 부여했습니다 .
• GCM 은 CTR 모드와 GHASH의 조합으로 2 ^ 128 개의 요소가있는 Galois 필드의 MAC 인 매우 빠르지 만 복잡한 조합입니다. TLS 1.2와 같은 중요한 네트워크 표준에서 널리 사용되는 것은 인텔이 GHASH 계산 속도를 높이기 위해 도입 한 특별 지침에 반영되어 있습니다.

추천:

인증의 중요성을 고려하여 대부분의 사용 사례 (디스크 암호화 목적 제외)에 다음 두 가지 블록 암호 모드를 사용하는 것이 좋습니다. 데이터가 비대칭 서명으로 CBC를 사용하여 인증되면 그렇지 않으면 GCM을 사용하십시오.

공식적인 분석은 2011 년 필 Rogaway에 의해 수행되었습니다 여기에 . 1.6 절에는 필자가 굵은 글씨로 강조하면서 여기에 내용을 요약 한 내용이 나와 있습니다.

이들 중 대부분은 IV가 무작위 여야하므로 예측할 수 없으므로 암호화 보안으로 생성해야합니다. 그러나 일부는 "nonce"만 필요로하는데,이 속성은 해당 속성을 요구하지 않고 재사용하지 않아도됩니다. 따라서 nonce에 의존하는 디자인은 그렇지 않은 디자인보다 오류가 덜 발생합니다 (그리고 CBC가 적절한 IV 선택으로 구현되지 않은 경우가 많았습니다). Rogaway가 "IV가 nonce 일 때 기밀성이 달성되지 않았습니다"와 같은 내용을 굵게 표시 한 것을 볼 수 있습니다. 이는 IV를 암호로 안전하게 (예측할 수 없음) 선택하면 아무런 문제가 없음을 의미합니다. 그러나 그렇지 않으면 좋은 보안 속성을 잃게됩니다. 이러한 모드 에서 IV 를 재사용하지 마십시오 .

또한 메시지 무결성과 암호화의 차이점을 이해해야합니다. 암호화는 데이터를 숨기지 만 공격자는 암호화 된 데이터를 수정할 수 있으며 메시지 무결성을 확인하지 않으면 소프트웨어가 결과를 받아 들일 수 있습니다. 개발자는 "복구 된 후 수정 된 데이터가 가비지로 돌아옵니다"라고 말하지만, 훌륭한 보안 엔지니어는 가비지가 소프트웨어에서 악의적 인 행동을 유발할 가능성을 찾은 다음 해당 분석을 실제 공격으로 바꿉니다. 암호화가 사용되었지만 메시지 무결성이 실제로 암호화보다 더 필요한 많은 사례를 보았습니다. 필요한 것을 이해하십시오.

GCM에는 암호화와 메시지 무결성이 모두 있지만 매우 취약한 디자인입니다. IV를 다시 사용하면 망가져 공격자가 키를 복구 할 수 있습니다. 다른 디자인은 덜 취약하기 때문에 실제로 보았던 불량한 암호화 코드의 양에 따라 GCM을 추천하는 것이 개인적으로 두렵습니다.

메시지 무결성과 암호화가 모두 필요한 경우 두 가지 알고리즘을 결합 할 수 있습니다. 일반적으로 CBC와 HMAC가 표시되지만 CBC와 연계 할 이유는 없습니다. 알아야 할 중요한 사항은 먼저 암호화 한 다음 암호화 된 내용을 MAC 으로 지정하는 것입니다. 또한 IV는 MAC 계산의 일부 여야합니다.

IP 문제를 알지 못합니다.

이제로가 웨이 교수의 좋은 점들에 대해 :

암호화 모드, 메시지 무결성이 아닌 암호화 모드

ECB : 블록 암호, 모드는 각 n 비트 조각을 개별적으로 암호화하여 n 비트의 배수 인 메시지를 암호화합니다. 보안 속성이 약한데 ,이 방법은 블록 위치와 시간 모두에서 블록의 동등성을 유출합니다. 상당한 레거시 가치와 다른 체계의 빌딩 블록으로서 가치가 있지만,이 모드는 일반적으로 바람직한 보안 목표를 자체적으로 달성하지 못하므로 상당한주의를 기울여 사용해야합니다. ECB는 "일반 목적"기밀 모드로 간주되어서는 안됩니다 .

CBC : IV 기반 암호화 체계 인이 모드는 확률 적 암호화 체계로 안전하며 임의 IV를 가정하여 임의의 비트와 구분할 수 없습니다. IV가 단순히 nonce 이거나 표준에서 잘못 제안한대로 체계에서 사용하는 것과 동일한 키로 암호화 된 nonce 인 경우 기밀성이 유지되지 않습니다 . 암호문은 매우 가단성입니다. 선택한 암호문 공격 (CCA) 보안이 없습니다. 많은 패딩 방법에 대해 올바른 패딩 오라클이있는 경우 기밀성이 유지되지 않습니다. 암호화는 본질적으로 연속적이기 때문에 비효율적입니다. 널리 사용되는이 모드의 개인 정보 보호 전용 보안 속성은 자주 잘못 사용됩니다. CBC-MAC 알고리즘의 빌딩 블록으로 사용할 수 있습니다. CTR 모드에 비해 중요한 이점은 없습니다.

CFB : IV 기반 암호화 체계 인이 모드는 확률 적 암호화 체계로 안전하며 임의 IV를 가정하여 임의의 비트와 구분할 수 없습니다. IV가 예측 가능 하거나 표준이 잘못 제안한 것과 같이 체계가 사용하는 것과 동일한 키로 암호화 된 nonce에 의해 작성된 경우 기밀성이 유지되지 않습니다 . 암호문은 가단성입니다. CCA 보안이 없습니다. 암호화는 본질적으로 연속적이기 때문에 비효율적입니다. 체계는 매개 변수 s, 1 ≤ s ≤ n, 일반적으로 s = 1 또는 s = 8에 따라 달라집니다. s 비트 만 처리하기 위해 하나의 블록 암호 호출이 필요하지 않습니다. 이 모드는 흥미로운 "자기 동기화"속성을 달성합니다. 암호문에 임의의 수의 s 비트 문자를 삽입하거나 삭제하면 일시적으로 올바른 암호 해독이 중단됩니다.

OFB : IV 기반 암호화 체계 인이 모드는 확률 적 암호화 체계로 안전하며 임의 IV를 가정하여 임의의 비트와 구분할 수 없습니다. 고정 된 IV 시퀀스 (예 : 카운터)가 제대로 작동하지만 IV가 nonce 인 경우 기밀성이 유지되지 않습니다. 암호문은 매우 가단성입니다. CCA 보안이 없습니다. 암호화 및 암호 해독은 본질적으로 연속적이기 때문에 비효율적입니다. 모든 비트 길이의 문자열을 기본적으로 암호화합니다 (패딩 필요 없음). CTR 모드에 비해 중요한 이점은 없습니다.

CTR : IV 기반 암호화 체계 인이 모드는 nonce IV를 가정하여 임의의 비트와 구분할 수 없습니다. 안전한 nonce 기반 방식으로이 모드는 무작위 IV를 사용하는 확률 적 암호화 방식으로도 사용할 수 있습니다. nonce가 암호화 또는 암호 해독에 재사용되면 프라이버시가 완전히 실패합니다. 모드의 병렬성은 종종 다른 기밀 모드보다 훨씬 빠르며 일부 설정에서는 훨씬 빠릅니다. 인증 된 암호화 체계의 중요한 구성 요소입니다. 일반적으로 개인 정보 보호 전용 암호화를 달성하는 가장 좋고 현대적인 방법입니다.

XTS : IV 기반 암호화 체계 인이 모드는 각 n 비트 청크에 조정 가능한 블록 암호 (강력한 PRP로 보안)를 적용하여 작동합니다. 길이를 n으로 나눌 수없는 메시지의 경우 마지막 두 블록이 특별히 처리됩니다. 이 모드의 유일한 사용은 블록 구조 저장 장치에서 데이터를 암호화하는 것입니다. 기본 PRP의 폭이 좁고 최종 최종 블록의 열악한 처리가 문제입니다. (와이드 블록) PRP 보안 블록 암호보다 더 효율적이지만 덜 바람직합니다.

MAC (메시지 무결성이지만 암호화는 아님)

ALG1–6 : MAC의 모음으로 CBC-MAC를 기반으로합니다. 체계가 너무 많습니다. 일부는 VIL PRF로 안전하고 일부는 FIL PRF로 안전하고 일부는 확실한 보안이 없습니다. 일부 체계는 손상 공격을 허용합니다. 일부 모드는 날짜가 있습니다. 키 분리는 해당 모드에 적합하지 않습니다. 일괄 적으로 채택해서는 안되지만 선택적으로“최상의”계획을 선택할 수 있습니다. CMAC에 유리하게 이러한 모드 중 어느 것도 채택하지 않는 것이 좋습니다. 일부 ISO 9797-1 MAC은 특히 은행 업무에서 널리 표준화되고 사용됩니다. 표준 개정판 (ISO / IEC FDIS 9797-1 : 2010)이 곧 출시 될 예정입니다 [93].

CMAC : CBC-MAC를 기반으로하는 MAC 모드는 (VIL) PRF (기본 블록 암호가 PRP라고 가정)로 (생일 한도까지) 안전합니다. CBCMAC 기반 체계에 대한 최소한의 오버 헤드. 본질적으로 일부 응용 프로그램 도메인의 문제는 직렬 특성이며 64 비트 블록 암호와 함께 사용하면 가끔씩 키를 다시 입력해야합니다. ISO 9797-1 MAC 모음보다 깨끗합니다.

HMAC : 블록 암호 대신 암호 해시 기능을 기반으로하는 MAC (대부분의 암호 해시 기능은 자체적으로 블록 암호를 기반으로 함). 선호하는 가정이 아니라도 메커니즘은 강력한 보안 가능성을 누리고 있습니다. 문헌에서 다수의 밀접하게 관련된 변이체는 알려진 것을 이해하는 것을 복잡하게한다. 해로운 공격은 제안 된 적이 없습니다. 널리 표준화되고 사용됩니다.

GMAC : GCM의 특별한 경우 인 nonce 기반 MAC. GCM의 많은 장점과 단점을 상속합니다. 그러나 nonce-requirement는 MAC에 불필요하며 여기서는 별다른 이점이 없습니다. 태그가 ≤ 64 비트로 잘리고 해독 범위가 모니터링 및 축소되지 않은 경우 실제 공격. non-reuse에서 완전한 실패. GCM을 채택하면 어쨌든 사용이 암시됩니다. 별도의 표준화에는 권장되지 않습니다.

인증 된 암호화 (암호화 및 메시지 무결성)

CCM : CTR 모드 암호화와 원시 CBC-MAC를 결합한 nonce 기반 AEAD 체계. 본질적으로 직렬이며 일부 상황에서 속도를 제한합니다. 기본 블록 암호가 좋은 PRP라고 가정하면 좋은 경계로 안전하게 보호 할 수 있습니다. 명백히 그 일을하는 불건전 한 건축. GCM보다 구현이 간단합니다. nonce 기반 MAC으로 사용할 수 있습니다. 널리 표준화되고 사용됩니다.

GCM : CTR 모드 암호화와 GF (2128) 기반 범용 해시 함수를 결합한 nonce 기반 AEAD 방식입니다. 일부 구현 환경의 우수한 효율 특성. 태그 잘림을 최소화한다고 가정하면 보안 성이 뛰어납니다. 실질적인 태그 잘림이있는 경우 공격 및 취약한 보안 가능성 한계. nonce 기반 MAC으로 사용할 수 있으며이를 GMAC라고합니다. 96 비트 이외의 nonces를 허용하는 의심스러운 선택. nonces를 96 비트로 제한하고 태그를 96 비트 이상으로 제한하는 것이 좋습니다. 널리 표준화되고 사용됩니다.

1. ECB 이외의 것.
2. CTR을 사용하는 경우 각 메시지마다 다른 IV를 사용해야합니다. 그렇지 않으면 공격자가 두 개의 암호문을 사용하여 암호화되지 않은 일반 텍스트를 파생시킬 수 있습니다. 그 이유는 CTR 모드가 본질적으로 블록 암호를 스트림 암호로 바꾸고, 스트림 암호의 첫 번째 규칙은 동일한 키 + IV를 두 번 사용하지 않기 때문입니다.
3. 모드를 구현하기가 얼마나 어려운지 실제로 큰 차이는 없습니다. 일부 모드에서는 블록 암호 만 암호화 방향으로 작동해야합니다. 그러나 AES를 포함한 대부분의 블록 암호는 암호 해독을 구현하는 데 더 많은 코드를 사용하지 않습니다.
4. 모든 암호 모드의 경우 처음 몇 바이트에서 메시지가 동일 할 수 있고 공격자가이를 알고 싶지 않은 경우 각 메시지마다 다른 IV를 사용하는 것이 중요합니다.

Wikipedia- Block cipher 작동 모드 에 대한 정보를 읽으면서 시작 하셨습니까? 그런 다음 Wikipedia의 NIST : Block Cipher Modes 작동에 대한 권장 사항 링크를 참조하십시오 .

널리 사용 가능한 것을 기반으로 선택하고 싶을 수도 있습니다. 나는 같은 질문을했고 여기에 제한된 연구 결과가 있습니다.

하드웨어 제한

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

오픈 소스 제한

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

한 가지 측면을 알고 있습니다. CBC는 각 블록마다 IV를 변경하여 보안을 강화하지만 무작위로 액세스 한 암호화 된 콘텐츠 (예 : 암호화 된 하드 디스크)에는 적용 할 수 없습니다.

따라서 순차 스트림에는 CBC (및 기타 순차 모드)를 사용하고 무작위 액세스에는 ECB를 사용하십시오.