-1

I am building an application where users send files with a password for encryption to a server via ssl. They can then share the encrypt files with people

I will then build a desktop application in C++ where a user can select the file and decrypt it locally on thier desktop with a password

Option1:PGP My first thought was to use pgp, now if i securely stored a private and public keypair on the server then all users files could be enceypted easily enough on the server with the users password. But my desktop application wont be able to decrypt the file with just a password i would have to bake the private key into my desktop application

Question1: if my desktop application is compiled could an attacker decompile the application and get hold of the private key, is there a way to securely store data in a compiled program to prevent such a breach.

Option2: AES Another method i thought was that i use a hashing algorithm to hash the users password and then use that hash as a key for encrypting the file using AES encryption. Then on my desktop application i use the same hashing algorithm to recreate the key when the recipent of the file enters the password to decrypt the file

Question2: same problem, if an attaker decompiles my program and see what hashing algorithm im using am i back to square one, now they can just generate hashes and brute force the file open

Question3: does anyone know of a better way to implement this

Dr Manhattan
  • 141
  • 6
  • Option 2: What if someone forgets the password? – Limit Aug 20 '16 at 02:30
  • 3
    What problem are you trying to use encryption to solve? – Alexander O'Mara Aug 20 '16 at 02:34
  • Limit: then they loose thier data and we will warn them upfront. @Alexander: we are trying to solve the problem of secure file transfer between people. If sending sensitive contracts to someone via email for instance email can be compromised but the files will stay locked – Dr Manhattan Aug 20 '16 at 07:45

2 Answers2

1

I'm not sure I understand the use case well enough, but have you considered just using GPG (or similar) in symmetric mode? No messing with key pairs, just passphrases. Per the GPG manual, the command to encrypt using symmetric encryption only is --symmetric or just -c, and it will prompt you for the passphrase. You can also specify to use ASCII armoring, if that would be helpful. Decrypt the resulting blob as usual (just passing it to gpg with no other arguments works) and it will prompt you for the passphrase again to decrypt.

There are lots of other tools that will symmetrically encrypt and decrypt files, although some of them are very poorly designed. I haven't actually specifically examined how good GPG is here, because anybody who I want to send an encrypted file to and who has GPG themselves, I just use asymmetric encryption. However, if you for some reason want to use symmetric crypto, using an already-existing and well-trusted cross-platform program like GPG seems like a good idea.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • Thanks for answering. How does this symetric encryption fair from a brute force attack vs AES with a slow key derivation function mentioned by Dude – Dr Manhattan Aug 20 '16 at 07:49
  • It definitely uses an iterated hash function (the relevant API in libgcrypt, `gcry_kdf_derive`, also supports using scrypt). It's hard to tell what KDF it's using and with what parameters, short of pulling the whole codebase and walking backward through it; their git web interface isn't very good. The simple answer is probably "*Yes, it's using a slow key derivation function, but I don't know which one or how slow.*" – CBHacking Aug 20 '16 at 22:07
1

Assume your client application can and will be decompiled and don't go with your first option of storing the private key. Disregarding the potential for decompilation, this would be bad practice anyway since you would be using the same key for each file.

Instead, use a solid encryption algorithm like AES and a slow password based key derivation function (e.g. PBKDF2). If you implement this well (do some research on Block Cipher Modes, Initialization Vectors, Salts, and Iterations), then it won't matter if an attacker knows the algorithm. The strength will reside in the password which isn't (or at least shouldn't be) stored anywhere. Implement strong password policies (e.g. don't allow short, simple passwords). Good Luck!

Dude
  • 26
  • 1
  • Thanks for this. Does encrypting symmetrically via GPG wrap bith steps of AES and slow key derivation into one step. Or is it more advantageous to use AES and stay away from symetric encryption – Dr Manhattan Aug 20 '16 at 07:53
  • I'd like to clearly state here, for the record: If you have to ask a question like this (which is a perfectly reasonable question, but shows a clear lack of experience with InfoSec and especially crypto), you should *definitely* not implement your own encryption system. There are an absurd number of ways to get this stuff wrong, most of them are pretty counterintuitive or at least hard to grok, and even people who've been doing this for years get it wrong (see all the issues with older SSL/TLS versions, etc.). You will not do better than them! **Don't try to roll your own crypto software!** – CBHacking Aug 20 '16 at 23:12
  • @DrManhattan: "Or is it more advantageous to use AES and stay away from symmetric[sic] encryption" - If you don't know why that is an *utterly absurd* thing to say/ask (hint: what kind of cipher is AES?) then you really, really need to go do a lot more basic research before you even consider writing your own crypto software. Take it from somebody who has been there: you don't know what you're doing, and you *will* get it wrong. Use existing software, and *not* something where you're ever working at the level of cipher primitives like choosing a block cipher or mode of operation. **Seriously.** – CBHacking Aug 20 '16 at 23:15