0

I'm developing an application that will encrypt a bunch of files the client has on their machine and then send them to a server, to back them up. I need to encrypt the files so that other clients/third parties can't access them. The problem is that I'd like to have a key hard-coded, to reduce the complexity of my program, but I can't have all clients share the same key or have third parties decompile the binary file to get the key (I know that hard-coded keys are a Bad Idea). Note that it's not viable to use plain assymetric key encryption since the performance would not be good enough.

The solution I've came up with consists of hard-coding the public key of a public-private key pair that belongs to the server, which I would use to encrypt a symmetric key, and then generate a random number (used as a symmetric key), encrypt the necessary files with it and then encrypt the symmetric key with the public key and send it to a database on the server, over a network. The point t of using assymetric key encryption is so that the transmission of the key is secure.

How secure is this protocol? Will it suffice to use a PRNG? Is there a better existing protocol?

closed as unclear what you're asking by M'vy, user45139, Stephane, WhiteWinterWolf, Xander Sep 8 '15 at 15:57

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Why does it matter if the client knows the public key? Can you provide more detail on what you are attempting to guard against? – user79537 Sep 7 '15 at 8:00
  • 1
    Your actual goal remains unclear to me. On one side, "I need to encrypt a bunch of files on a client", and on the other "the client can't know about the key" (Can't know? Mustn't know?). If your goal is to make the client encrypt with a key unknown to it, then yes the design seems mostly flawed to me. If the client need to encrypt using a key unknown to other client, then the design is good except that I don't get the usefulness of the public/private key pairs (maybe some client should be able to share some data? Maybe the data should be accessible by the server?). – WhiteWinterWolf Sep 7 '15 at 8:11
  • 1
    Can you describe more precisely what you're attempting to do here ? because from what I read, there are several good answers to your questions and which one is the best for your case depends on what you're specifically attempting to do. Could you describe your application ? – Stephane Sep 7 '15 at 8:27
  • Okay, I am a bit confused, and it looks like @Stephane and WhiteWinterWolf are looking for the same clarification. So, let's back up a little. If you give the client a public key, you would be doing asymmetric encryption. One of the benefits being that the client wouldn't be able to decrypt the files once encrypted. If you want symmetric encryption, that would seem to be counter-intuitive to the description we have so far. What's the intended application? – user79537 Sep 7 '15 at 8:57
  • 1
    @HexTitan I think we're bothj looking for more or less the same thing because there is an obvious hole in the question: if the client already has access to the cleartext, then either the random key creation step is pointless, or the purpose of the application is to make the cleartext unavailable to the client (fi. cryptolocker kind of maleware) or the OP hasn't properly explained the situation. I think it would be easier to understand the question with a description of the goal of the process instead of the steps taken to achieve it. – Stephane Sep 7 '15 at 9:42
3

What you have thought through on your own is the standard way of doing encryption for network traffic:

  1. Generate a random symmetric key,
  2. Encrypt entire "message" using symmetric key (plus IV, nonce, etc),
  3. Encrypt symmetric key using target's (in this case, your central server) public key,
  4. Destroy the 'plaintext' symmetric key,
  5. Ship the encrypted goods to the destination(s).

Your concern regarding PRNG is correct. Since you are probably using an encryption package of some kind (usually a library in your programming language), there is probably a cryptographically-secure random number generator in that package. Do NOT rely on standard PRNGs (rand(), rnd(), etc). Also, make sure that the encrypted bytes are converted to a usable format for transmission, as most common transmission protocols tend to choke on raw binary. Base64 "ASCII armor" is the standard.

Not the answer you're looking for? Browse other questions tagged or ask your own question.