Take the 2-minute tour ×

First off, I'm not very familiar with encryption best-practices.

My use-case is simple: I'm creating an application that will be reading encrypted documents and decrypting them dynamically to do some operation on the data that they contain.

I was reading that I should use 128-bit or 256-bit AES, so I installed OpenSLL to my Linux box to see how encryption / decryption is done. I encrypted and decrypted a sample document and notice that AES requires a passphrase.

How can I store this passphrase in my application securely so that somebody cannot easily reverse engineer the binary, discover my passphrase, and decrypt the documents outside of the application?

share|improve this question
you can use bcrypt to protect the password –  Andrew Smith Aug 4 '12 at 0:33
@AndrewSmith As I understand it, bcrypt is a one-way hashing function. This is only useful for verifying user-provided passwords. The OP seems to be asking about storing passwords for the application to use directly. This requires the password to be stored in a reversible form. I'm pretty sure though, when you start heading in that direction, it's turtles all the way down. –  Iszi Aug 4 '12 at 1:25

2 Answers 2

up vote 4 down vote accepted

What you're talking about, essentially, is DRM. If you provide the user with the data you're trying to protect in any unencrypted form, they have the data and can make copies. It's on their machine, you've given it to them.

  • If you use AES, or any form of symmetric cryptosystem an attacker can reverse-engineer your application and discover the key.
  • If the key is only provided at runtime, they can load your program into a debugger and set a breakpoint to capture the key.
  • When you decrypt the document, anyone can set a breakpoint on your decryption routine and capture the plaintext buffer from memory.

Packing, obfuscation and anti-debug tricks are trivial to bypass for anyone that's even reasonably skilled at reverse engineering. This is self evident; think about every major game / software title that's come out in the last 20 years. Every copy-protection mechanism has fallen to reverse engineering. The same goes for malware and media DRM.

All of this boils down to one thing: Anything you put on your client's computer is theirs to modify and analyse.

I have a feeling that your situation needs to be re-thought. Rather than coming up with a potential solution and trying to find ways to make that work, think about alternative solutions. Can the document processing be done on a central server, out of the hands of the user?

share|improve this answer
+1. The only way to secure the encryption process is to have it done server sided. –  Terry Chia Aug 4 '12 at 8:50
+1. Triviality of bypassing packing, obfuscation and anti-debug tricks –  Prowla Aug 4 '12 at 9:13
Thanks for the reply Polynomial. I had considered processing the document on a central server, however feared that it may suffer in performance. Most of the application is centered around processing these documents, so if it were to be done on a server, the application would be nothing more than a front-end to the server. I couldn't hand-off just the decryption to the server, because it still doesn't make sense to have the plaintext document sent back to the application. That seems like it'd be easier to attack than the passphrase within the original application. –  nickb Aug 8 '12 at 14:13

Generally you can't stop a determined or experienced hacker. My suggestion is not to worry too much because unless you have a lot of users (or money) it is unlikely anyone is going to put any serious effort towards hacking your application; Concentrate on delivering a fantastic piece of software.

However you can:

Avoid storing passwords as string literals - This should be obvious.

Obscure your passphrases - Use a collection of plain english words or random characters to buffer your passphrase to possibly confuse the hacker or to make the passwords less obvious.

Obscure symbol names - There is a possibility a hacker could extract obvious symbol names from your binary. For example, class keyChain. You can mislead while maintaining readability by using #define keyChain readModule.

Obscure application flow - Say the hacker works backwards from the file decryption to find the passphrase, you could use function pointers to obscure the appeared application flow.

Generate your passphrase at runtime - You write your own function that generates and spits out your passphrase during runtime.

Encrypt / Decrypt passphrase with your own function - If you use another third party library an attacker can look for common calls. Obviously be smart with this and don't use some form of the caesar cipher, and remember to only use this to hide your passphrase, that is, still use AES from OpenSSL for your actual data encryption and decryption. However this will lead you back to the start of safely storing a password. The gain is in the attempt to prevent the hacker from searching common decryption/encryption function calls.

Regardless, none of these will completely stop a hacker. They may slow down or prevent a novice, or they may do absolutely nothing.

Work on making your software that great that bypassing it straight to decryption is unattractive. Convince users that your software is worth using.

share|improve this answer
This is bad advice. #1 rule of crypto is "crypto is hard". #2 rule of crypto is "don't roll your own". Obfuscation is just obscurity. –  Polynomial Aug 4 '12 at 8:29
@polynomial - I didn't mean make your own algorithm (don't reinvent AES). I meant your own implementation of a standard in your code. That way you aren't referencing external libraries. –  Prowla Aug 4 '12 at 8:31
That's almost as bad. Implementation is difficult, and easy to get wrong. It's beside the point, though. You cannot solve the DRM problem. –  Polynomial Aug 4 '12 at 8:32
I agree with you. I wasn't trying to say any of those points was a solution. My opinion is to not worry about it or rethink what you are providing and how. The methods I shared you can use in an attempt to deter the average hacker. I need to rethink how share my thoughts. Thank you for the response :) –  Prowla Aug 4 '12 at 8:51
And lest I appear too positive: I don't have figures (I don't know if anyone does), but I'm convinced that a large majority of vendors who decide to use obfuscation end up losing far more money than they gain. But there have been a few success stories, especially in the gaming industry where the objective is only to resist during the first few weeks of sales (because that's when most of the profits are made) and most attackers get bored fast (as soon as the next game comes out). –  Gilles Aug 4 '12 at 12:19

Your Answer


