it-swarm-korea.com

PBKDF2 기반 System.Cryptology.RFC2898DeriveBytes ()가 기존 방법보다 유니 코드 암호 해싱에 "더 나은"방법입니까?

일반적인 해시와 비교하여 RFC2898DeriveBytes 를 사용하는 것이 언제 적절한가요?

업데이트

이제 KDF는 일반적으로 스트림 암호화에 사용할 수있는 대칭 키를 만드는 데 사용됩니다. 또한 PBKDF2가 PasswordDeriveBytes 를 더 이상 사용하지 않는 것으로 이해합니다. 이 질문의 목적은 해시 된 비밀번호를 저장하는 강력한 방법으로 KDF를 다시 사용하는 가능성을 탐색하는 것입니다. 내가 암호화하려는 내용은 사람이 컴퓨터에 기억하고 입력 할 수있는 유니 코드 문자열입니다.

KDF에 관심이있는 이유는

  1. Rainbow 테이블을 만드는 데 느리고 계산 비용이 많이 듭니다.
  2. .NET의 기본 라이브러리는 FIPS 승인되었으며 SHA-256을 사용하는 경우이 KDF를 NIST 권장 사항 과 함께 사용할 수 있습니다

질문

일반적인 해싱 방법과 달리 KDF를 사용하는 것에 대한 인수는 무엇입니까? (면책 조항 : is 일반적인 해싱 방법은 무엇입니까?)

15

암호를 해시하고 저장할 때 NIST PBKDF2 승인 이지만 원래 의도 된 것은 아닙니다. 특히 StackExchange는 같은 목적으로 PBKDF2 을 사용합니다. 소스 코드는 여기에 있습니다.

BCrypt와 PBKDF2를 비교하려면 이 답변 을 참조하십시오. BCrypt는 암호를 저장하는 가장 일반적인 방법입니다.

PBKDF2는 .NET에 내장되어 있으므로 이미 FIPS 호환)이므로 PBKDF2를 고려하고 있습니다.

14

PasswordDeriveBytes는 PBKDF1 키 파생 함수를 구현합니다. KDF는 비밀 데이터 (여기서는 "비밀번호", 즉 사람의 뇌에 적합하고 사람의 손가락으로 입력 할 수있는 데이터의 종류)를 필요한 알고리즘에 적합한 일련의 비트로 변환하는 함수입니다. 대칭 키 (예 : 대칭 암호화). KDF는 다른 용도, 특히 암호 저장을위한 것이 아닙니다.

필요한 대칭 키가 해시 함수 출력 크기보다 크지 않은 경우 해시 함수를 KDF로 사용할 수 있습니다. 그러나 그러한 KDF는 매우 조잡합니다. 좋은 KDF가 제공해야하는 기능 중 하나는 충분히 느리다입니다. "비밀번호"는 본질적으로 철저한 검색 ( "사전 공격"이라고도 함)에 취약하기 때문입니다. 사용자는 몇백 만 또는 수십억 번의 시도로 추측 할 수있는 단순한 단어 나 조합 대신 비밀번호로 선택하는 경향이 있습니다. 주어진 시스템에서, 일반적으로 비교적 느린 KDF를 허용 할 수있다 : 인증을 시도하는 사용자는 키 파생 함수에 대해 1µs와 1ms 지연 사이의 차이를 보지 못할 것이다; 그러나 공격자에게는 1000 배의 둔화가 치명적입니다. 그것은 하루의 침입 노력을 3-years 파괴의 노력으로 변환합니다.

PBKDF1에는 "반복 횟수"가 포함되어 있는데, 이는 키 파생을 구성 가능한 방식으로 적절하게 느리게 만들기위한 것입니다. 간단한 해시 함수는 너무 빠릅니다. KDF로 사용하는 것은 해시 함수보다 PBKDF1을 선호하는 곳입니다. 실제로 PBKDF1은 권장되지 않습니다. 동일한 표준 의 PBKDF2가 더 강력해야합니다.

해시 함수는 KDF보다 훨씬 일반적인 객체이며 KDF가 충족하지 못하는 다른 용도가 많이 있습니다.

당신이하고 싶은 것은 불분명합니다 : 당신은 "서명"이라는 용어를 사용하는데, 이는 일반적으로 RSA 또는 ECDSA와 같이 "비대칭 디지털 서명"을 의미합니다. MAC 와 같이 대칭 무결성 검사를 지정하기 위해 "서명"이라는 용어를 사용하는 경향이있는 사람들이 있습니다 ( "서명"이라고 부릅니다) 하지만 널리 퍼져 있습니다). 그러나, 이것은 어느 시점에서 비밀, 즉 키를 수반하며 해시 함수는 키가 없습니다.

16
Thomas Pornin

내가 놓친 것이 아니라면 PasswordDeriveBytes 및 기타 PBKDF 구현은 암호를 저장하기위한 것이 아니며 "일반적인"해시 대신 사용되지도 않습니다.

의도 한 것은 사용자가 제공 한 암호를 기반으로 대칭 암호화를위한 암호화 키를 만드는 것입니다.

명확히하려면 다음 상황을 고려하십시오.
파일을 암호화해야하는 응용 프로그램이 있습니다. 이것은 사용자의 재량에 따라 이루어지며 원하는대로 해독 할 수 있습니다.
아, MS Word에 내용을 암호화하는 기능이 있다고 가정하겠습니다. 또는 암호화 된 Zip 파일입니다.
사용자에게 액세스 권한을 부여하고 싶지만 사용자가 의존하여 강력하고 무작위로 정확하게 256 비트 키를 생성하고 싶지 않아서 기억하기 어렵습니다. 기타.
따라서 사용자는 원하는 암호를 설정하고 derive 암호 키를 설정할 수 있습니다.

비밀번호를 저장하거나 간단한 해시를 사용하여 비밀번호를 저장하는 시점은 없습니다. 키 자료 만 작성하기위한 것입니다.

6
AviD

PBKDF2는 10 년 전에 RFC 2898 에서 더 이상 사용되지 않는 PBKDF1보다 낫습니다. .NET에 대해 Rfc2898DeriveBytes 클래스 (System.Security.Cryptography)

또한 Java 6 현재 SunJCE에 PBKDF2 : PBKDF2WithHmacSHA1 구현이 있음을 알게되어 기쁩니다.

BlackBerry App Security-Stack Overflow 에서 논의한 바와 같이 이전 버전의 Java의 경우 PBKDF2의 구현은 A free Java RFC 2898/PKCS # 5 PBKDF2

그러나 SHA-256을 사용하는 것이 SHA-1보다 낫다면 지금은 더 이상 사용되지 않습니다.

4
nealmcb

단순 반복 횟수가 아닌 RFC2898DeriveBytes를 사용하는 것이 인증 목적으로 스트레이트 해시 기능을 사용하는 것보다 낫습니다.

먼저 소금을 넣어야하며 개발자가 하드 코드 소금처럼 바보 같은 것을 할 수는 있지만 개발자가 일반적으로 소금이 아닌 엉망인 곳보다 적어도 한 걸음 더 가까워집니다. 소금 만 가지고 있으면 레인보우 테이블이 이미 존재하기 때문에 다른 사람의 암호를 사용할 수 있으며 각 사용자에 대해 무작위로 소금을 바르면 여러 사용자가 동일한 암호를 가질 때 정보 유출을 막고 쉬운 암호를 만들기가 매우 어렵습니다. 각 소금에 대한 테이블을 생성해야하기 때문에 얻을 수 있습니다.

RFC2898DeriveBytes는 불행히도 해시 함수를 선택할 수 없으며 HMAC-SHA1을 사용하므로 PBKDF1과 비교하여 좋은 점은 키 크기가 실제로 원하는 크기만큼 클 수 있으므로 실제로 문제가되지 않습니다. 따라서 레인보우 테이블을 표준 해시 알고리즘과 비교하여 저장 및 배포하기가 어렵습니다.

마지막으로 반복 횟수가 중요합니다! 해시 계산 속도를 크게 낮추고 표준 해시 알고리즘은 빠르도록 설계되었으며 데이터 스토리지는 기하 급수적으로 증가하고 있습니다. 키 크기만으로는 믿을 수 없습니다.

3
jbtule

OP의 질문과 상기 질문의 목표는 다소 모순된다. 모두가 지적했듯이 PBKDF2는 주로 암호 enc/storage가 아니라 키 생성에 사용됩니다. 가장 일반적으로 WPA2 PMK 및 기타 WPA 키 생성 체계에서 암호 + SSID 이름의 소금 및 SSID 이름 길이와 같은 구성 요소를 사용하여 사용됩니다. 4096 반복 SHA1 해싱.

패스를 암호화 할 때 보안을 위해 필요한 가장 중요한 것은 길이와 동적이며 사용자에게 투명하지 않은 솔트입니다 (즉, 악용자가 솔트가 무엇인지 결정할 수 없음). 최소 20 자 암호, 임의의 솔트 및 SHA-256의 4K + 반복 (PBKDF2에서 목적에 대해 최소 1K 반복 SHA1 권장)을 가진 AES 암호화 저장소를 사용하는 경우 해커는 시간이 매우 어려워집니다. 암호 (참조 : 더 이상은 아니라면 몇 년 또는 수십 년).

암호 암호화는 최종 사용 (속도, 보안 수준의 필요성 등)에 따라 크게 달라 지므로 최종 사용 가능성을 모른 채 이상적인 솔루션을 권장하기가 더 어렵습니다.

1
mrnap