Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am interested in understanding the format of the encrypted files produced by the application Data Guardian. From what I can tell some sort of transformation of the password is stored in the field named 'hexIdentifier.' What I find odd is that if two files are saved with the same password, then they both have the same 'hexIdentifier' string. I am not advertising this app and I am not affiliated with the company. I am evaluating the app.

share|improve this question
2  
It wouldn't be much of an advertisement anyway if the password is stored in the file itself. –  Andrew Lambert Feb 8 '12 at 1:21
    
This whole thread is an awesome read. I know nothing about nothing about the implementation of file encryption. All I know is to stick to what the experts use. –  surfasb Feb 8 '12 at 9:48
add comment

1 Answer

up vote 6 down vote accepted

I would be very surprised if it did actually store the password (encoded or not) in the encrypted file because doing so would demonstrate a fundamental lack of understanding of cryptography, in which case, it would be highly recommended to pass over the software if you need the encrypted files to be secure. There is no practical reason to store the password.

Even the low price is not a reason to use it if it does indeed store the password since there are plenty of other programs that are much more secure and even free (in fact, even standard archivers provide secure encryption functionality (without storing the password).


As for Data Guardian, I’ve got some bad news. I did some tests and you and Amazed are correct. It seems that the hexIdentifier field is not only related to the password, but it is not even a hash, it is the actual password! (albeit encoded, though not even with a large alphabet).

If you save the same file over and over with a password of increasing size (eg one character, two chars, three…) it will cause the field to change, but the size remains constant (64-bit), up to eight characters, then from nine to 16 characters, the field changes to 128-bit, and so on. In other words, it chunks (pads?) and encodes the password in 8-character blocks. If it were a hash, the size of the field would remain constant no matter the length of the password. Therefore, it actually encodes and stores the password itself.

There is a DLL in the program folder that indicates that it uses the Blowfish block-cipher (which uses 64-bit blocks—remember the 64-bit chunks above?), so the password is likely encrypted with that as well as the data (though separately from the data as opposed to as part of the same stream, which makes it even more vulnerable).

I’ve already ferreted out several aspects of the algorithm in just a few minutes of merely running in-program tests (while at the same time watching TV) without opening it in a disassembler or looking at a single line of code. I don’t imagine it would be too difficult for someone with the proper motivation to reverse it altogether.


In summary, Data Guardian is not reliable enough if you need encryption (sort of defeats the purpose of the name). If you don’t need the encryption or the data isn’t sensitive, then you can get by with it (it is a specialized record-keeping program as opposed to a generic encryption program). Otherwise if security is necessary, then you would be better off looking for another record management program with stronger encryption or else just use a normal program (or even Data Guardian) and encrypt the saved files with a generic encryption program (or NTFS encryption).

You could also contact the dev and ask if they can implement stronger encryption (even the standard Microsoft crypto API [1][2][3][4] would be good; also Crypto++ is common since Boost could not add one).

share|improve this answer
    
+1 My thoughts exactly. –  Andrew Lambert Feb 8 '12 at 1:34
    
It does look as though the HexIdentifier tag is directly linked to the password. It may not be that it is the password, but there is a correlation. –  Andrew Lambert Feb 8 '12 at 1:44
    
Probably a hash. Even that is inadvisable. It’s not hard to encrypt a small file with different passwords to derive the hashing function (especially if it is a standard one like MD5, SHA-1, etc.), then reverse the password via brute-force. –  Synetech Feb 8 '12 at 1:50
1  
> A password is whatever I choose it to be. 11 randomly selected alphanumeric characters (A-Z, a-z, 0-9) already achieve over 64 bit @Dennis, a password is whatever the algorithm limits to. The size of the password depends on the alphabet. If I only allow the characters {abc}, then a four-character password does not mean 32,768 permutations (32-bit), it is only 81 permutations. Much easier (and faster) to crack. –  Synetech Feb 8 '12 at 3:00
1  
@bpqaoozhoohjfpn, what analysis? I mean that they may or may not be legally responsible for depending on what they claim. If they say it uses strong encryption (especially if they specifically state algorithms and such), and a breach occurs, they may be taken to court for false claims, but if they admit weak encryption (or maybe even don’t say anything unless specifically asked), then they may argue that they never claimed it was secure. For example, if I say I am a carpenter then build a crappy chair, you could sue, but if I admit to being awful, then you can’t really complain, now can you? –  Synetech Feb 8 '12 at 3:18
show 28 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.