Re: Opening an Encrypted DB_File database

[iburrell]

The solution: don't encrypt the whole DB_File. The Berkley DB library wants to deal with the database file on disk. The best solution is not encrypt the whole file, but the individual keys and values that you want to protect.

One trick you could use is to decrypt to a temporary file, tie with DB_File, and unlink the file. Unix systems will keep the file around until the filehandle is closed. DB_File supports anonymous maps that work this way. The problem is relying on Berkeley DB not opening new filehandles or closing its existing filehandles. Also, it makes getting the modified file difficult.

Another trick is put the unencrypted database file on a RAM disk that is only readable by the user running the script.

[crabbdean]

Hi iburrell, I've already encrypted each key/value pair in the DB_File database using a 256 bit cipher. But I was discussing with my flatmate who works for the government doing cryptography and she said it would be wise to also encrypt the file. I'm trusting her judgement on that.

I attempted to unlink the file as suggested. Doesn't work as DB_File puts a lock on it. The temp file opens the vulnerability of leaving a decrypted version lying around which I would really like to avoid.

I'm unsure how to go about putting it onto a ramdisk. Can you suggest further on how to go about this?

Thanks for your help.

[MidLifeXis]

If you encrypt a file with a known format (like a DB file), wouldn't an attacker have information to assist in decrypting the entire file? I thought it was recommended not to encrypt data that was predectible or known, because it gave a target to shoot for.

Just my $0.02 USD.

--MidLifeXis

[crabbdean]

Yeah, I thought about that ... but considered its better than not encrypting it at all. If I left it unencrypted they definitely would know the format.

In addition I've written it to use 2 ciphers both with different 256 bit keys, and both keys are based on two different passwords which are themselves encrypted by two different 256 bit ciphers. On top of that the contents of the file is encrypted in a different cipher than the file encryption. Additionally the contents remains in an encrypted state in memory. The GUI requires an 8 digit password plus an 8 digit pin that can only be entered manually via a keypad on the GUI, and the program has a 30 second delay before it runs again. That should stop any brute force attempts. Any other ideas are welcome. :-)