Encrypting\Decrypting File Text

I'm wondering what the most secure method for encrypting text would be in my c++ app. The text is not transmitted or anything, so from what I understand a private-key (symmetric) encryption is what I would be looking for.

I see a lot of programmers use "custom" algorithms ranging from a simple XOR to more complex algos. While many use the official Microsoft CryptoAPI. Personally, I'd think the "custom" route quite possible (unless a lot of time were spent on it) would be easier to crack.

Having read quite a bit on this stuff tonight, I am left with a few questions I'm hoping can be answered:

1) Is a private-key the proper encryption technique for file text?
2) Is there ANY advantage to a custom algo over what the CryptoAPI offers?
3) Specifically what algo would be recommended (i know microsoft offers several)
4) Wouldn't calling an API function with a "private key" be extreamly insecure? Is the private key passed in plain text?

Thanks for any assistance,
PG

1. Well if it is for you alone then private key is the way to go. However if you plan on sharing this with anyone then you need to go with public key.

2. Custom algorithms are for people who don't understand anything at all about encription! You always want to go with a strong algorithm when you go to protect your information. They have been seen by the worlds best at math and survived.

The best idea would probably be to use the cryptoAPI from microsoft. It has a good random gen and so forth. However if you go cross platform then you would need to follow an algorithm on your own in something like C. Which I would avise getting a very good book on it because there is many ways you can screw up even while using a good cipher.

3. Microsoft plugs some of the best in there. RC2, RC4, DES, Triple DES, and even AES and all of them have survived the test of time.

You can always encipher in more then 1 thing. Such as first enciphering in RC4 then AES and use 2 unique keys for each. That way if they did crack one, it wouldn't be that obvious.

4. I think I would be more worried about a keyboard sniffer then anything. There is just too much memory for people to constantly watch however a keyboard sniffer is fine. But now you just learned something, encryption is only a lock and its only as strong as the thing its locking. If someone can't pick the lock, they can always try kicking down the door.

Cool, that answers a lot of the questions I had.

However, in my application, the user will not be entering the password. The encrypted\decrypted file's key (i suppose) will have to be hidden as best as I possibly can in the executable. Is this correct?

If so, this big nasty encryption doesn't do much good in defence against prying eyes...no? Seems like once the cracker identifies what type of encryption is used and fishes the password out of the EXE, nothing has been gained as they can call their own CryptoAPI's to dump the file contents.

If I'm understanding that correctly, then in my situation where the user has no responsibility for "holding" the password, is there some other method\protection offered to protect a secret CryptoAPI key (besides packing the EXE)?

Thanks for the recommendations and help thus far!
PG

Also, what is a key blob?

I see it in a few examples of file encryption I've seen.

Well basically a key usually is stored in a byte array and each byte array contains a key in a format which is called key blob.

Blob = Binary large object

I managed to dig this up at msdn:


http://search.microsoft.com/gomsuri....ob_formats.asp

Quote:

---

However, in my application, the user will not be entering the password. The encrypted\decrypted file's key (i suppose) will have to be hidden as best as I possibly can in the executable. Is this correct?

---

I'm not for sure what you are trying to accomplish. It would sorta defeat the purpose of **Private key** encryption to put the password out like that. It would be like having this huge lock to protect something with the key stuck in it.

With public key encryption, the data is encrypted with the publicly-available public key, but then cannot be decrypted without the corresponding private key.

The two are mathematically related, so theoretically it can be cracked. It just takes a bloody long time (think a few times the age of the Universe :p). The private key is usually stored encrypted with a different strategy, encrypted against a passphrase -- this is a lot longer than a password and provides greater security.

If you want to have any kind of security, the private key must *never* leave its owner, and if it does, it must be revoked immediately, and replaced with a new key pair.

Basically, in your case, the user must enter the password.