.NET(C#)에서 데이터 암호화(주로 AES)를 이용할 때의 메모

.NET을 사용한 암호화 구현에 대해 걱정할 수 있었기 때문에 메모.

신경이 쓰인 것

온라인 문서의 일본어 번역이 엉망이었기 때문에, 영어로부터 인용입니다.
요컨대, AesCryptoServiceProvider 이나 AesManaged 라든지는 보통은 사용하지 않고 좋고, Aes 를 사용하면 좋다, 라고 읽을 수 있습니다. 인터넷의 사이트를 여러가지 보고 있으면 만드는 방법이 여러가지 같고, 어느 클래스를 사용하는지 헤매었지만. 아무래도 보고 있으면, 기본은 Aes.Create() 로 인스턴스를 만들면 설정치는 추천의 것이 자동으로 들어가는 것 같네요(그런 식으로 읽을 수 있었다).

In most cases, you don't need to directly reference an algorithm implementation class, such as AesCryptoServiceProvider. The methods and properties you typically need are on the base algorithm class, such as Aes.

.NET Cryptography Model

확실히, MS 사이트의 예를 보면, Aes aes = Aes.Create() 라고 하는 예가 많네요. 덧붙여서, 이 Create 의 Factory 메소드의 인수에는 알고리즘(AES, AesManaged, AesCryptoServiceProvider)을 지정할 수 있으므로, 어떤 형태가 되돌아오는지 조사해 보았습니다.

검증 코드, 출력 결과는 다음과 같습니다.

검증 프로그램

using System;
using System.Security.Cryptography;

Aes def = Aes.Create();
Aes aes = Aes.Create("AES");
Aes aesManaged = Aes.Create("AesManaged");
Aes aesCSP = Aes.Create("AesCryptoServiceProvider");

AesManaged managed = new AesManaged();
AesCryptoServiceProvider CSP = new AesCryptoServiceProvider();

Console.WriteLine(def.GetType().Name);
Console.WriteLine(aes.GetType().Name);
Console.WriteLine(aesManaged.GetType().Name);
Console.WriteLine(aesCSP.GetType().Name);
Console.WriteLine(managed.GetType().Name);
Console.WriteLine(CSP.GetType().Name);

출력 결과

AesImplementation
AesCryptoServiceProvider
AesManaged
AesCryptoServiceProvider
AesManaged
AesCryptoServiceProvider

"AES"의 경우는 AesImplementation이므로 AesManaged와는 다른 클래스가 사용되는 것 같습니다. 아래에도 쓰고 있지만 AesCryptoServiceProvider는 Windows 구현을 호출하는 래퍼입니다.

관리되는 녀석은 FIPS 인증되지 않았습니다.

알고리즘의 명칭에 Magageed가 붙는 것은 말 그대로 완전한 매니지드로서 기술되고 있는 것입니다만, MS의 문서에 의하면 FIPS 인정되어 있지 않습니다. FIPS (Federal Information Processing Standards)는 미국 정부 조달에 관한 표준입니다 (FIPS 140-2의 경우 암호화 모듈이 충족해야하는 요구 사항을 정의합니다). 요컨대, FIPS 인정이 없는 것은 제삼자의 묵 첨부가 없기 때문에, 그 이외를 사용하는 것이 무난이라고 하는 것입니까(오히려 자세한 쪽이 있으면 가르쳐 주었으면 한다).

AesManaged.cs (GitHub)

if (CryptoConfig.AllowOnlyFipsAlgorithms) {
    if (LocalAppContextSwitches.UseLegacyFipsThrow) {
        throw new InvalidOperationException(SR.GetString(SR.Cryptography_NonCompliantFIPSAlgorithm));
    }

AesCryptoServiceProvider 는 Windows 기능(CAPI) 래퍼와 같습니다. 이 소스를 보면 AllowOnlyFipsAlgorithms는 보지 않는 것 같습니다. FIPS 인증을 받는 것이 좋습니까?

AesCryptoServiceProvider.cs

Rijndael

.NET의 Rijndael (및 그것을 상속 한 RijndaelManaged)은 SymmetricAlgorithm 클래스를 상속하지만 Aes도 마찬가지로 SymmetricAlgorithm를 상속합니다.

Rijndael은 AES와 비교해, 블록 길이가 256bit까지의 32bit의 배수로 선택할 수 있지만(열쇠 길이에 대해서도 마찬가지), AES는 열쇠 길이가 128bit, 192bit, 256bit의 3종류만. 그리고 블록 길이가 128bit밖에 선택할 수 없다.

요컨대, AES와는 별도의 클래스. 어느 쪽이 좋은가… 오히려, 있다면 큰 소란이 될 것이다. 널리 사용되고 있기 때문에.

보충: Windows가 FIPS 인증 사용을 강제하는 방법

MS의 기사에서, 이런 것을 발견했다(영어입니다만).

FIPs and .NET Core

위에서 쓴 FIPS 인증의 사용을 강제시킬 수 있는 것 같지만, 그룹 정책의 편집으로 가능하게 되는 것 같다. 다만, 변경한 후에 어떻게 될지가 무섭기 때문에, 검증은 하고 있지 않습니다.

중반 메모이므로, Qiita의 기사같지 않을지도 모릅니다만, 양해해 주십시오.