0

I have a file transfer site which allows users to upload data into an incoming directory. The uploads are to be encrypted and then moved out of the incoming directory and into an archive directory which is not directly accessible from the server application.

Four other user need to work with the encrypted files. They will download the encrypted files from the archive directory and decrypt on their workstations.

As I understand:

if a password is used (symmetric), and one of the four persons leave the organization, they may still know the password to the encrypted data. Even though they may not have physical access to the files, an attack vector still exists. To mitigate, all current archive files could be decrypted, and re-encrypted with a new passphrase, but this only works well until the file size and quantity approach a detrimental process time.

If shared-keys (asymmetric) are used, all files would need to be encrypted four times (one file per pub-key). This adds confusion to the workflow and obviously storage capacity consumed is now 4x more.

What is the best method for encrypting files to share with multiple people?

Server Fault
  • 3,714
  • 12
  • 54
  • 89

2 Answers2

1

For this, I'd consider using something like Hashicorp's Vault. It can both manage keys as well as provide encryption and decryption as a service. This means that none of your users (or file servers) have access to the keys - they use their own credentials to call out to Vault, which performs crypt actions on their behalf.

All actions are of course logged for auditing purposes.

EEAA
  • 109,363
  • 18
  • 175
  • 245
0

Your assumption about asymmetric encryption is wrong.

Asymmetric encryption is almost never used to encrypt user data directly, for it would be too slow and impractical.

Instead, most products implement a hybrid scheme, where the data is encrypted with a randomly chosen symmetric key, then the random key is encrypted using an asymmetrical algorithm.

With such a system, if you have multiple recipients, the random symmetric key is simply encrypted once for every recipient.

For RSA and ECC, the overhead corresponds to the size of the public key, so for instance about 256 bytes for 2048bit RSA. Elgamal has the double of that. Still pretty much irrelevant if your files are large.

Regarding the re-encryption issue, consider your security model: can you prevent your users from making unauthorized copies of the data ? you probably cannot. Then, it may be a moot point to reencrypt old data; removing them from the recipient list for future files may be sufficient.

b0fh
  • 3,313
  • 1
  • 21
  • 32
  • Ahh.. so generate a random passphrase on the server to encrypt the upload (symmetric), then save that passphrase itself to a separate file which is encrypted with the user's public key (asymmetric)? That's brilliant! The slower encryption is used on a smaller chunk of data while allowing for the passphrase to be shared or revoked -- if a user leaves the 'ring of trust' simply do not encrypt the passphrase for them. Is that about right? No, you cannot trust users to stick to the security policy. When they don't, it's an HR issue. I just need to do what I can to best secure the data. – Server Fault Jun 16 '17 at 15:09
  • Yes, but you don't need to do this yourself, most products that do asymmetric encryption already implement that. For instance, if you use GnuPG, you simply give it a list of multiple recipients, and you will see that the size overhead is roughly the size of each recipient's public key, and not the cleartext size multiplied by the number of recipients. – b0fh Jun 18 '17 at 13:46