암호를 키 또는 IV로 직접 사용하는 대신 .NET에서 Rfc2898DeriveBytes 클래스를 사용해야하는 이유는 무엇입니까?

Question

Rfc2898DeriveBytes를 사용하는 것과 단지 Encoding.ASCII.GetBytes(string object);을 사용하는 것의 차이점은 무엇입니까?

나는 두 접근법 중 어느 것이 든 상대적으로 성공했다. 전자는 후자가 간단하고 요점은 더 긴 접근 방식이다. 두 가지 모두 당신이 결국 똑같은 일을 할 수있게 해주는 것처럼 보이지만 나는 후자보다 앞선 것을 사용함에있어 고심하고 있습니다.

내가 이해할 수있는 기본 개념은 문자열 암호를 바이트 배열로 변환하여 대칭 암호화 클래스 인 AesManaged에 사용할 수 있다는 것입니다. RFC 클래스를 사용하지만 rfc 객체를 만들 때 소금 값과 암호를 사용합니다. 나는 그것의 더 안전하다고 생각하지만 여전히 무식한 추측이다. 또한 특정 크기의 바이트 배열을 반환 할 수 있습니다. 지금하여 .KEY 또는 설정으로 사용할 수 있습니다

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password"); 

또는

string password = "P@%5w0r]>"; 
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt"); 
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray); 

'rfcKey'개체 : 여기에

내가에서 오는하고 어디를 보여주는 몇 가지 예입니다 .IV 속성 은 대칭 암호화 알고리즘 클래스입니다.

즉.

RijndaelManaged rj = new RijndaelManaged(); 
rj.Key = rfcKey.Getbytes(rj.KeySize/8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize/8); 

'rj'가 준비되어야합니다!

혼란스러운 부분 ... 'rfcKey'개체를 사용하는 것보다 내'myPassInBytes'배열을 사용하여 'rj'개체를 설정할 수 없습니까?

VS2008에서이 작업을 시도했지만 즉각적인 대답은 아니오입니다. 그러나 위에서 언급 한 다른 대안보다 RFC 클래스가 사용되는 이유에 대해 교육받은 답을 얻었습니까?

Answer 1

정말로 사용자 키를 암호 키로 직접 사용하고 싶지 않습니다. 특히 AES가있는입니다.

Rfc2898DeriveBytes는 PBKDF2를 구현 한 것입니다. 그것이하는 일은 소금과 함께 사용자 비밀번호를 반복 해싱하는 것입니다. 여기에는 여러 가지 이점이 있습니다.

먼저 임의로 크기가 지정된 비밀번호를 사용할 수 있습니다. AES는 특정 키 크기 만 지원합니다.

둘째, 소금을 추가한다는 것은 동일한 암호를 사용하여 여러 개의 다른 키를 생성 할 수 있음을 의미합니다 (소금은 상수가 아니라고 가정합니다). 이는 키 분리에 중요합니다. 다른 컨텍스트에서 키를 재사용하는 것은 암호화 시스템이 손상되는 가장 일반적인 방법 중 하나입니다.

여러 번의 반복 (기본적으로 1000 개)으로 인해 암호 추측 공격이 느려집니다. AES 키를 추측하려는 사람을 생각해보십시오. 방금 암호를 사용했다면 이것은 간단 할 것입니다 - 각 가능한 암호를 키로 시도하십시오. 반면 PBKDF2의 경우 공격자는 먼저 에 대해 각각 암호 추측을 위해 1000 회의 해시 반복을 수행해야합니다. 따라서 사용자의 속도가 약간 느려지는 반면 공격자에게는 불균형 한 효과가 있습니다. (실제로 훨씬 더 높은 반복 횟수를 사용하는 것이 일반적이며 10000이 일반적으로 권장됩니다).

최종 출력 키가 균일하게 배포됨을 의미합니다. 예를 들어 암호를 사용한 경우 키의 128 비트 중 일반적으로 16 비트가 0 (높은 ASCII 비트)이됩니다. 비밀번호 찾기를 무시하더라도 바로 바로 keysearch를 65536 배 더 쉽게 만들 수 있습니다.

마지막으로, AES에는 관련된 주요 공격과 관련된 특정 취약점이 있습니다. 관련 키 공격은 공격자가 일부 키로 암호화 된 데이터를 알고 있고 이들 사이에 알려진 (또는 추측 된) 관계가있는 경우 가능합니다. 예를 들어, "My AES key sucks"(AES-128의 경우 16 바이트)와 "MY AES KEY SUCKS"의 암호 키를 사용하여 데이터를 암호화 한 경우 관련된 키 공격이 가능할 수 있습니다. 현재 가장 잘 알려진 공격은 실제로 이런 방식으로 전체 AES를 차단할 수는 없지만 시간이 지남에 따라 점진적으로 개선되고 있습니다. 지난 주에 AES-256을 사용하여 13 라운드 (총 14 개 중)를 돌파하는 새로운 공격이 게시되었습니다. 관련된 키 공격. 시간이 지남에 따라 더 좋아지지 않는 그런 공격에 의지하는 것은 현명하게 현명하지 않을 것입니다.

Answer 2

짧은 답변 : 더 안전합니다. 같은 이유로 System.Security 네임 스페이스에 특수 임의 생성기가 있습니다.

자세한 내용은

, 나는 하나 개의 작은 부분을 이해 RFC2898

참조 : Encoding.ASCII.GetBytes()는 긴 암호를 사용하는 경우, 가장 첫 번째 rj.KeySize 바이트에서 사용할와

그것의. 나머지는 무시됩니다. 그리고 패스워드가 keysize보다 짧으면 패딩을 추가해야합니다. (단지 0의 증가 취약점이 추가됩니다).