Entropy Mixing

한 사건을 담은 두 기록을 생각해 보세요. 파일 이름이 달라도 두 번째 기록이 독립적인 미지의 정보를 더하는 것은 아닙니다. 마찬가지로 패킷 도착 시각과 디스크 접근 시각도 서로 관련될 수 있습니다. NIST SP 800-90B는 종속된 원천의 엔트로피 추정치를 단순히 더할 수 없다고 경고합니다. 먼저 공격자가 다른 입력까지 알 때 무엇이 여전히 불확실한지 확인해야 합니다. [1]

해시는 데이터에서 계산해 얻는 지문 같은 값입니다. 하지만 공격자가 모든 입력을 알면 같은 결과를 계산할 수 있습니다. 긴 해시나 공개 상수를 추가해도 알려진 입력이 비밀로 바뀌지는 않습니다. RFC 4086은 기존 불확실성을 혼합하는 것과 결정론적으로 값을 더 만들어 내는 것을 구분합니다. 올바르게 설계된 혼합은 원천이 실제로 제공하는 것을 활용하며, 없는 엔트로피를 대신하지 못합니다. [2]

XOR는 비트를 비교해 같으면 0, 다르면 1을 냅니다. 따라서 X XOR X = 0입니다. 여기서는 값을 자기 복사본과 결합하면 불확실성이 모두 사라집니다. 반대로 한 입력이 균등한 난수이고 다른 입력과 독립적이면 결과도 균등합니다. RFC 4086은 이 예로 전제 조건의 중요성을 보여 줍니다. 지갑 생성기를 직접 만드는 설명서는 아닙니다. [2]

구체적인 설계를 평가할 때는 입력이 어디서 오며 공격자가 무엇을 할 수 있는지 살펴야 합니다. 암호학적 키를 유도하는 방법인 HKDF는 salt라는 보조 입력을 사용합니다. 비밀일 필요는 없지만 RFC 5869는 원래 키 재료와 독립적이라고 가정하며, 애플리케이션이 공격자의 선택이나 변경을 막도록 요구합니다. 여기서 Salt는 매개변수 이름입니다. 원천 목록이나 무작위처럼 보이는 출력만으로는 원천이 고장 났을 때의 안전성을 보장할 수 없습니다. [4]

NIST SP 800-90B는 주된 잡음 원천을 기준으로 삼습니다. 다른 원천의 출력을 그 데이터에 이어 붙일 수 있지만, 함께 conditioning이라는 검증된 처리 과정을 거쳐야 합니다. 이 평가 방식에서는 추가 원천의 엔트로피를 더 인정하지 않습니다. 입력이 많아져도 인정되는 양이 자동으로 늘지 않는다는 뜻입니다. 이는 특정 평가의 규칙이지, 다른 원천이 결코 도움이 되지 않는다는 말은 아닙니다. [1]

OpenSSL 3.5에서 그 차이를 볼 수 있습니다. 프로그램이 암호화나 난수를 다룰 때 사용할 수 있는 암호 라이브러리입니다. RAND_add() 함수는 버퍼, 즉 데이터를 보관하는 메모리 영역에서 입력을 가져와 섞습니다. num은 읽을 바이트 수를 지정하고, randomness는 그 엔트로피를 0부터 num까지 바이트 단위로 추정합니다. 메모리 영역의 크기가 이 추정치를 입증하지는 않습니다. 기본 생성기는 보통 스스로 초기화하고 시스템 원천에서 엔트로피를 자동으로 보충합니다. [3]

생성기에 새로운 엔트로피를 보충하는 것을 reseeding이라고 합니다. 아무 데이터나 더하는 것과는 다릅니다. OpenSSL 3.5 문서에 따르면 암호 모듈 규칙을 따르는 FIPS 모드에서는 애플리케이션이 제공한 데이터를 신뢰된 엔트로피 원천으로 인정하지 않습니다. 추가 입력으로 섞을 뿐이며 완전한 reseed로 계산하지 않습니다. 따라서 RAND_add()를 호출했다는 사실만으로 그런 갱신이 이루어졌다고 할 수 없습니다. [3]

RFC 5869의 HKDF는 작업을 HKDF-Extract와 HKDF-Expand로 나눕니다. 첫 단계는 입력에서 이용할 수 있는 엔트로피를 중간 키에 모으고, 다음 단계는 그 키로부터 필요한 길이의 데이터를 유도합니다. 별도의 독립적인 비밀을 새로 얻는 것은 아닙니다. info 매개변수는 유도한 키의 목적을 표시하는 등 출력을 사용 맥락에 연결할 수 있습니다. 그런 맥락이 좋은 초기 데이터를 대신하거나 새로운 엔트로피가 생겼음을 입증하지는 않습니다. [4]