Jump to content
  • Advertisement
Sign in to follow this  
flounder

password protected files

This topic is 4435 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In my application, a file packer (think winzip), i'm trying to add encryption. The encryption is going to require a key (password) to make sure the encryption method is unique. While i can think of 1000 different ways to encrypt the data i can't think of any way to somehow hide the password in the packed file without it being easy to recover by people looking to decrypt the data. I need to be able to tell if the user entered a correct or incorrect password during the unpacking process becuase the data will also be decompressed, and I need the data to be in it's unencrypted state to decompress correctly. To determine if the password entered by the user is correct, i've though of: Placing pieces of the password throughout the packed file, for instance place a character of the password every X bytes. During unpacking the user's password would be compared against these bytes. As an alternative to hiding the password, i've thought of having a segment of bytes of all the same value at the beginning of the file. During packing, these bytes will be encrypted and if during decryption the bytes don't turn out to be all the same then the password is invalid. And a third method is to combine the above two. I know that it is impossible to store the password in the file without it being recoverable by someone else, but the methods i mentioned seemed too niave to me. Does anyone have any suggestions or alternatives to hiding a password in the packed file so that i can immediatly tell if it matches the one the user enters?

Share this post


Link to post
Share on other sites
Advertisement
Easy, don't save the password. Use an encryption method that can undo itself by applying the same encryption method to the data, i.e. original_data=Decrypt(encrypted_data,password)=Encrypt(Encrypt(original_data,password),password). Just store a hash of the original data with the file, and use it to verify the decrypted data.

A simple way to do this is to use a hash of the password to seed a customized PRNG, and then simply XOR the output of the PRNG with the data. The result will be encrypted data, and if you then perform the exact same process on the encrypted data, the original data will be returned.

[Edited by - Mastaba on June 25, 2006 11:14:39 PM]

Share this post


Link to post
Share on other sites
Mastaba: i semi-understand what you're saying. From what i found out (see sentence below) hashing is a good method for encryption, but it seems unreasonable to have to store hashes for each file in the packed file when i can just store one hash for the password.

Undergamer: Yes that's quite a long list! I was able to come across this, however, and in the article it reccommends hashing the password in the file, and claims good hashes as being virtually unbreakable by modern day computers.

Since hashing seems to be what's reccommended i'll research it some more. Thanks to you both!

Share this post


Link to post
Share on other sites
Storing the hash of the password is as good as storing the password itself... if the user can attach a debugger to your application he can simply replace the hash value of the password he entered with the hash value he got from the file.

EDIT: It seems I misread your original question, so storing a hash might work in your case, because you're using the password for decrypting data. It wouldn't work where you rely on the hash for authentication.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Mastaba
A simple way to do this is to use a hash of the password to seed a customized PRNG, and then simply XOR the output of the PRNG with the data. The result will be encrypted data, and if you then perform the exact same process on the encrypted data, the original data will be returned.


Nevermind the fact that an encryption method like that could probably be cracked with a pencil and paper, it's a pretty bad encryption method, especially considering there are tried and true encryption methods you can use for free.

As for the original question - one way of doing it is storing a hash (preferrably salted) of the password inside the encrypted block. If you want a fast method, store it as the first item inside. If you don't mind a slower, more secure, method - don't store anything at all, except possibly a hash of the unencrypted data (inside the encrypted block itself, of course). If the hash doesn't match the unencrypted data block after attempting to decrypt, you know the password was wrong.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
[quoteNevermind the fact that an encryption method like that could probably be cracked with a pencil and paper, it's a pretty bad encryption method, especially considering there are tried and true encryption methods you can use for free.[/quote]

Really? With pencil and paper? So, this method, which is very similar to RC4 could be cracked by someone without a machine? In that person's lifetime? Would you dare to take a crack at decoding a string a bytes for me with pencil and paper? I'm challenging you Anonymous Poster. I'll post a string of encrypted bytes using this type of method that 'can be cracked with pencil and paper'. I will gladly even give you a generous 3 month deadline to crack it. So what's it going to be Anonymous Poster? Are you man enough?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
Really? With pencil and paper? So, this method, which is very similar to RC4 could be cracked by someone without a machine? In that person's lifetime? Would you dare to take a crack at decoding a string a bytes for me with pencil and paper? I'm challenging you Anonymous Poster. I'll post a string of encrypted bytes using this type of method that 'can be cracked with pencil and paper'. I will gladly even give you a generous 3 month deadline to crack it. So what's it going to be Anonymous Poster? Are you man enough?


Tell you what, to demonstrate that your method is insecure, I propose the following:

1) Disclose the method you used exactly.
2) Take a jpeg file, encrypt with your method.

After that, I will attempt to crack it. Of course, if I fail, you have to reveal the password to prove you didn't post garbage.

All of the commonly used freely available encryption algorithms (AES, Blowfish, etc.) would easily pass that test, but the method you described would probably not. If the method is like you described, I promise I'll do the crack without using the computer to perform any computations to do it (that is, a "pencil and paper" crack).

How about it?

Share this post


Link to post
Share on other sites
I don't understand why all this fuss about encryption modes or hashing.

OP: use an irreversible hash function (sha1/md5/other) on the password and store that hash in an uncrypted section of the file. Then, use another hash function to create a key, and use that key to encrypt the data using any private-key algorithm you wish. When the user attemps decryption, hash the password and check it against the hash stored in the uncrypted section. It it matches, attempt to use the other hash as a key. If it does not match, or if the other hash is not a valid key, tell the user he's wrong.

Mastaba: using a hash as a seed for a PRNG and generating a number is the same as using a hash, only longer.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!