1

I'm a bit lost here as I've never had this issue before. One of our clients wants to have our source code in case we dissapear for whatever reason. We are eager to comply but the source code is our only asset in our company. They agreed to accept the source code encrypted and once every year check that the "whatever method we choose" works and that the file we are uploading to their server works. We will use a third party that will hold the key or password to the files in case we disappear.

  • Is it safe to use Public/Private key approach?

  • Or are there other methods that could improve our safety?

EDIT: After reading comments and Luis Casillas answer I'd like to improve my question by adding some info. Even though we trust some bit the client, we do not trust "others" IT security. We're looking into worse case scenario they're hacked and our source code is leaked. I know it sounds paranoiac but this software is our only asset. I think the ceremony approach is what we're looking for here and specifically my question is about step 6. Let's say we gather in a room with the escrow agent and my client. They agree that the source code is legit. What's the safest way to encrypt it? Will a public key encryption work against brute-force attack? How can I reduce the chances of the code being decrypted without the "secret password". Thanks for all the comments, this is our first time doing this and all the comments are greatly appreciated.

  • 2
    Usually when giving clients source code, it's protected merely legally: in the contract you specify that they can't sell it / use it / etc. and if they do you can bring them to court. There's a lot less of a guarantee, but it's much simpler, and companies are very invested in not getting into legal troubles. – Boycott SE for Monica Cellio Oct 26 '16 at 0:56
  • 2
    Putting the source code in legal escrow is by far a more normal way of handling this... ask on law.stackexchange.com? – gowenfawr Oct 26 '16 at 0:58
1

In any case, your whole scenario seems to make a number of assumptions that sound rather magical. For example:

They agreed to accept the source code encrypted and once every year check that the "whatever method we choose" works and that the file we are uploading to their server works.

How can they check whether the file you upload to their server "works," if not by decrypting it? If they can decrypt it once a year, why can't they decrypt it any time they want? And even if (somehow!) they truly can only decrypt it once a year, why can't they then hold on to the decrypted source forever?

Once you consider these questions it sounds to me like what you're proposing to do has to be way more complex than you're making it sound:

  • You absolutely need to show your source code to the client to get any scheme to work, because otherwise they can't know that the encrypted file you give them is actually your source code.
  • The method for showing them the source code cannot be giving them a plaintext copy of the code base, because then there's no point to giving them the encrypted file.
  • You need them to sign off that they are satisfied with your claim that what you showed them is indeed your source code and that the encrypted file you're giving them decrypts to the same as what you showed them.

So to make what you're describing truly work, you need a complicated ceremony, perhaps something along these lines:

  1. The client, the key escrow agent and you get together in one room.
  2. Either you provide a computer with a fresh operating system installation, installation of the tools needed to carry out the ceremony, no network connectivity, and the ability to read removable media.
  3. The client examines the computer and it installed software at length to satisfy themselves that the software installed in it is not malicious in any way.
  4. You copy your source code from removable media into the computer's hard drive.
  5. The client gets to examine the source code to satisfy themselves that it is authentic, but they're not allowed to copy it into external media.
  6. With the client witnessing, you run the commands to archive the source tree, generate a key, encrypt the archive, and copy the encrypted file into the client's choice of external media, that is then given to client.
  7. With the client witnessing, you run the commands to copy the key into the client's choice of external media, which is then given to the escrow agent.
  8. You now all have to sign off that the ceremony was carried out to your satisfaction, or otherwise it's invalid.

And I bet I'm oversimplifying this by quite a bit. Take-home message: doing what you propose securely with parties that really do not trust each other, is much more complicated than you think. If you think this paranoid approach is excessive, then you are implicitly trusting your client, and perhaps it's best to codify that trust into contractual conditions than to pile on technical security stuff.

Is it safe to use Public/Private key approach?

The use of public key cryptography doesn't gain you anything here, because from the point of view of the client, you're just giving them an encrypted file and withholding the key that can decrypt it. So that key might as well be a symmetric one.

Or are there other methods that could improve our safety?

Secret sharing comes to mind, but it might be impractical with a very large file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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