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

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

---

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

나는 어느 쪽의 접근 방식 으로든 상대적으로 성공을 거두었고, 전자는 후자가 간단하고 요점에 더 긴 바람의 접근 방식입니다. 둘 다 결국 같은 일을 할 수있게하는 것 같지만 나는 후자보다 전자를 사용하는 요점을보기 위해 고군분투하고 있습니다.

내가 이해할 수 있었던 기본 개념은 문자열 암호를 바이트 배열로 변환하여 대칭 암호화 클래스와 같은 용도로 사용할 수 있다는 것 AesManaged입니다. RFC 클래스를 통해하지만 rfc 개체를 만들 때 솔트 값과 암호를 사용하게됩니다. 나는 그것이 더 안전하다고 가정하지만 여전히 그것은 기껏해야 교육받지 않은 추측입니다! 또한 특정 크기의 바이트 배열을 반환 할 수 있습니다.

다음은 제가 어디에서 왔는지 보여주는 몇 가지 예입니다.

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'객체를 사용하여 대칭 암호화 알고리즘 클래스에서 .Key 또는 .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 클래스가 사용되는 이유에 대해 더 잘 교육받은 답변을 받았습니까?

---

특히 AES 에서는 사용자 암호를 암호화 키로 직접 사용하고 싶지 않습니다 .

Rfc2898DeriveBytes는 PBKDF2의 구현입니다. 그것이하는 일은 솔트와 함께 사용자 암호를 반복적으로 해시하는 것입니다. 여기에는 여러 가지 이점이 있습니다.

첫째, 임의 크기의 암호를 사용할 수 있습니다. AES는 특정 키 크기 만 지원합니다.

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

다중 반복 (기본적으로 1000)은 암호 추측 공격을 느리게합니다. AES 키를 추측하려는 사람을 고려하십시오. 방금 암호를 사용한 경우 간단합니다. 가능한 각 암호를 키로 시도하십시오. 반면에 PBKDF2를 사용하는 경우 공격자는 먼저 각 암호 추측 에 대해 1000 번의 해시 반복을 수행해야 합니다. 따라서 사용자의 속도가 약간 느려지지만 공격자에게는 불균형적인 영향을 미칩니다. (사실 훨씬 더 높은 반복 횟수를 사용하는 것이 일반적이며 일반적으로 10000이 권장됩니다).

또한 최종 출력 키가 균일하게 배포됨을 의미합니다. 예를 들어 암호를 사용한 경우 일반적으로 키의 128 비트 중 16 비트는 0 (상위 ASCII 비트)이됩니다. 바로 거기에 즉시 암호 추측을 무시하고 키 검색이 생각보다 65536 배 더 쉬워집니다.

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

참고 URL : https://stackoverflow.com/questions/2659214/why-do-i-need-to-use-the-rfc2898derivebytes-class-in-net-instead-of-directly