30

I'm working on a project where we need to keep a few specific files easily accessible, but encrypted. My idea for accomplishing this is to have the files available in the project's public website, encrypted to all of the members' PGP keys. I know that in theory, this means that only those members can decrypt it, and the files are safe, but is there a risk I'm missing?

Chris
  • 403
  • 4
  • 6
  • 3
    Doesn't this scheme allow an attack on a member become an attack on all of the project? – Boluc Papuccuoglu Jul 15 '16 at 15:01
  • 7
    [Here's an excellent real-life example to complement our excellent answers.](http://www.spiegel.de/international/world/leak-at-wikileaks-a-dispatch-disaster-in-six-acts-a-783778.html) – Luis Casillas Jul 15 '16 at 16:03
  • Depending on what you are doing, other risks may include leaking the date at which those file appear, and leaking their approximate size. – Eldritch Conundrum Jul 23 '16 at 21:54

6 Answers6

37

There is always a risk that any given cipher will be broken at some point and data like this will become truly public. So yes there are some risks but it doesn't mean you aren't making a reasonable security trade-off.

A few things you may want to consider:

What's your worse case scenario with the data going public and are there implications to this data going public that you might not be aware of ?

Are there any time-based factors to this data, such as the data is only useful for a year, a week, etc ?

Are there any regulatory, legal, or ethical implications of this data going public ?

Can you add additional security controls such that it's not just one control protecting the data ?

Do the people you want to share this data with need ALL of the data or could they satisfy their needs with a smaller subset of data ?

Is data masking (replacing sensitive data with known fake data ) an option here which would provide additional security ?

Where will it be decrypted and where will the decryption keys be stored ?

Is the passphrase to decrypt it easy to brute force ?

etc... Millions of other questions go here.

Nothing is 100% secure, everything is a trade-off so you need to look at the decision from a few different angles first.

Generally my advice when I see a single security control is to tell you that you need additional levels of security controls rather than just one. So I would have to advise you to consider additional controls but again even then I don't know what you are protecting and if it's just a collection of Internet cat photos then hey maybe just using GPG is good enough... (no offense to GPG of course, that's a great tool but cat photos are everywhere)

Trey Blalock
  • 14,109
  • 6
  • 43
  • 49
  • 15
    "Nothing is 100% secure" - OTP is. Oh, wait, it's still susceptible to $5 wrenches and alcohol. – John Dvorak Jul 15 '16 at 04:40
  • 1
    OTP is also susceptible to sabotaged random number generators, and to your point wrenches. – Trey Blalock Jul 15 '16 at 06:06
  • 12
    With GnuPG, I would suggest using `--hidden-recipient` (`-R`) instead of `--recipient` (`-r`), or adding `--throw-keyids`, for this scenario. See the gpg(1) man page for details. It comes at a cost at decryption time because it means all available secret keys must be tried, but reduces the attack surface for a third party (who wouldn't know which keys are able to decrypt the file). – user Jul 15 '16 at 09:35
11

I think one of the biggest risks is that somebody is accidentally going to replace an encrypted file with its unencrypted version. Keeping the files in a private place protects against that. It's part of the concept of multilayered security that others have mentioned: when one layer is bypassed, whether maliciously or accidentally, you still have some protection in place to cover you while you realize what happened.

Never forget, the biggest vulnerability is (pretty much) always the people.

XKCD 538

David Z
  • 807
  • 7
  • 15
9

If you have confidence in the encryption (which you should), depending on your implementation, you might be leaking some kind of metadata, for example:

  • "user A is using the service", or
  • "user B configuration has not been updated since ...", or
  • "a new user C was recently created", or
  • "80% of users recently moved away from the service".
techraf
  • 9,149
  • 11
  • 44
  • 62
  • #2 can be bypassed by generating fake updates, such as a timestamp of when the download was initiated. – John Dvorak Jul 15 '16 at 04:36
  • 4
    Even things like "the transaction log is 24MB" or "the transaction log grows 20% faster over the weekend than during the week" might leak information about what happens inside your business. – anaximander Jul 15 '16 at 12:23
3

Assuming the cryptography is implemented correctly, if any the member's keys are exposed or hacked then your data is vulnerable.

The more people you have in this distribution, the greater the risk of information disclosure.

Also check out this link, Encryption and the "security time decay" of prior encrypted data

Community
  • 1
makerofthings7
  • 50,488
  • 54
  • 253
  • 542
1

No it's a pretty accepted practice to do this. Once encrypted, there really isn't any harm in having the encrypted file publicly accessible, assuming you've taken all the standard precautions:

  • Don't store the private keys in the same location
  • Routinely audit who has access and remove accordingly
HashHazard
  • 5,145
  • 1
  • 19
  • 29
0

It depends. It comes down to risk management.

By placing the payload into the public domain, you're betting against flaws being discovered in the cipher (and/or implementation), along with technology advancing sufficiently to brute-force the encrypted data.

If your data loses value over time, the above risks may be acceptable compared to the convenience you gain, however that's something you need to evaluate.

qnm
  • 101