애플리케이션에서 생성된 암호화된 파일의 형식을 이해하고 싶습니다.데이터 수호자. 내가 알 수 있는 바에 따르면 일종의 비밀번호 변환이 'hexIdentifier'라는 필드에 저장되어 있습니다. 내가 이상하게 생각하는 점은 두 파일이 동일한 비밀번호로 저장되면 둘 다 동일한 'hexIdentifier' 문자열을 갖는다는 것입니다. 저는 이 앱을 광고하는 것이 아니며 해당 회사와 아무런 관련이 없습니다. 앱을 평가하고 있습니다.
답변1
나는 될 것이다매우실제로 암호화된 파일에 암호(인코딩 여부)를 저장했다면 놀랐습니다. 그렇게 하면 암호화에 대한 근본적인 이해가 부족하다는 것을 보여줄 수 있기 때문입니다. 이 경우 암호화된 파일이 필요한 경우 소프트웨어를 전달하는 것이 좋습니다. 안전하기 위해. 비밀번호를 저장할 실질적인 이유는 없습니다.
비밀번호가 실제로 저장되어 있다면 가격이 저렴하더라도 사용할 이유가 되지 않습니다.풍부한~의다른 프로그램훨씬 더 안전하고 심지어무료(사실 표준조차도아카이버안전한 암호화 기능을 제공합니다(비밀번호를 저장하지 않음).
Data Guardian에 관해서는 나쁜 소식이 있습니다. 몇 가지 테스트를 해보니 당신과 Amazed가 맞습니다. 해당 hexIdentifier필드는 비밀번호와 관련된 것뿐만 아니라 해시도 아닌 것으로 보입니다 .실제 비밀번호!(큰 알파벳으로 인코딩되지는 않았지만 인코딩되었지만).
크기가 커지는 비밀번호(예: 1자, 2자, 3…)를 사용하여 동일한 파일을 반복해서 저장하면 필드가 변경되지만 크기는 최대 8자까지 일정하게(64비트) 유지됩니다. 그런 다음 9자에서 16자까지 필드가 128비트로 변경됩니다. 즉, 비밀번호를 8자 블록으로 분할(패딩?)하고 인코딩합니다. 해시인 경우 필드 크기는 비밀번호 길이에 관계없이 일정하게 유지됩니다. 따라서 실제로 비밀번호 자체를 인코딩하여 저장합니다.
프로그램 폴더에는 Blowfish 블록 암호(64비트 블록을 사용합니다. 위의 64비트 청크를 기억하십니까?)를 사용함을 나타내는 DLL이 있으므로 암호는 데이터뿐만 아니라 해당 블록으로 암호화될 가능성이 높습니다( 하지만 동일한 스트림의 일부가 아닌 데이터와 별도로 존재하므로 더욱 취약해집니다.)
나는 이미 디스어셈블러에서 알고리즘을 열거나 한 줄의 코드도 보지 않고 프로그램 내 테스트를 실행하는 동시에(TV를 보면서) 단 몇 분 만에 알고리즘의 여러 측면을 찾아냈습니다. 나는 적절한 동기를 가진 사람이 그것을 완전히 뒤집는 것이 너무 어려울 것이라고 생각하지 않습니다.
요약하자면, 암호화가 필요한 경우 Data Guardian은 충분히 신뢰할 수 없습니다(일종의 이름 목적에 어긋납니다). 그렇지 않으면필요암호화가 중요하지 않거나 데이터가 중요하지 않으면 그대로 사용할 수 있습니다(일반 암호화 프로그램과 반대되는 특수 기록 보관 프로그램입니다). 그렇지 않고 보안이 필요한 경우 더 강력한 암호화 기능을 갖춘 다른 기록 관리 프로그램을 찾거나 일반 프로그램(또는 Data Guardian)을 사용하고 일반 암호화 프로그램(또는 Data Guardian)으로 저장된 파일을 암호화하는 것이 좋습니다.NTFS 암호화).
당신은 또한개발자에게 연락하세요더 강력한 암호화(표준 Microsoft 암호화 API도 포함)를 구현할 수 있는지 물어보세요.[1][2][삼][4]좋을 것이다; 또한암호화++Boost가 하나를 추가할 수 없기 때문에 일반적입니다.)