1
$\begingroup$

So I need to encrypt a file server-side for transport from server to client and storage on client-side. I'm quite confused as to what I have to watch out for, as it seems like it's insanely easy to screw up really bad.

The files I need to encrypt

  • Are binary
  • Sometimes contain big areas of null bytes.
  • Are of medium size, usually < 1gb.
  • Usually start with the same or similar header, so plaintext will often be the same.
  • Dont need to be encrypted often, but decrypted often, as they will not be stored decrypted.
  • Should remain very secure for a long time.

What I thought I could do is to use AES-256 in OCB3 mode, as it seems to provide both authentication and encryption.

I'm however not very sure about how I would go about generating a suitable key from a password. Is using a simple hash function like SHA-256 secure?

I'm assuming I'll have to store the IV along with the file. Is that correct?

Would AES-256 in OCB3 mode be suitable for this sort of task or is there a better way of doing this?

By the way, I am aware that it's quite easy to read the decrypted file from memory when it's decrypted at client-side, but I'm afraid there's not much I can do about it.

Edit: Both server and client programs are written in c++. I also want to be able to encrypt and decrypt the files just in memory at runtime, so a lot of file encryption tools don't really fit the task.

$\endgroup$
5
  • $\begingroup$ Why wouldn't github.com/FiloSottile/age work? $\endgroup$ – SAI Peregrinus Aug 14 '20 at 16:03
  • $\begingroup$ I should probably edit this, I'm writing this in c++ and it should be able to encrypt files at runtime. $\endgroup$ – thebear8 Aug 14 '20 at 16:06
  • $\begingroup$ @SAIPeregrinus It doesn't really fit the task very well, I also clarified this in the question $\endgroup$ – thebear8 Aug 14 '20 at 16:09
  • 3
    $\begingroup$ Have you got a look at libsodium? I think it fits your needs: it's in C, and when using it you will not have to worry about all the question you ask here. You just have to follow the documentation and you'll be fine. $\endgroup$ – A. Hersean Aug 14 '20 at 16:25
  • $\begingroup$ @A.Hersean Thanks, I'll have a look at it. $\endgroup$ – thebear8 Aug 15 '20 at 12:17
4
$\begingroup$

I'm however not very sure about how I would go about generating a suitable key from a password. Is using a simple hash function like SHA-256 secure?

No, you'd generally use a Password Based Key Derivation Function such as a secure version of Argon2. But preferably, you'd not use a password at all. It is only one factor that's required and passwords generally do not contain enough entropy for long term storage.

One trick is to use a public key for hybrid encryption, and store the private key on a separate device that is only connected when the file needs to be decrypted. That private key in turn can be encrypted.

If you use a password, I'd use a password manager with a very large password.

I'm assuming I'll have to store the IV along with the file. Is that correct?

Not necessarily. The input of a PBKDF always contains a salt value to protect against rainbow tables. From the password and salt (as well as the work factor) the output keying material can be calculated. It is possible to retrieve both a key from the output bits and the IV from other output bits.

Of course, now you'd have to store the salt value.

Full file names are also unique and could be used for a mode of operation by hashing the filename. However, that means that the file cannot be copied to another location, so generally we would try and avoid such brittle constructions.

There is of course nothing particularly wrong by storing a (random) IV, as long as it is unique with a high probability.

Would AES-256 in OCB3 mode be suitable for this sort of task or is there a better way of doing this?

It's not better or worse than any other AEAD cipher I suppose.

By the way, I am aware that it's quite easy to read the decrypted file from memory when it's decrypted at client-side, but I'm afraid there's not much I can do about it.

Well, you should harden your clients to the best of your ability. But yeah, in the end you need to access the data, and it is too large to fit into any kind of secure enclave in all likelihood.

Edit: Both server and client programs are written in c++. I also want to be able to encrypt and decrypt the files just in memory at runtime, so a lot of file encryption tools don't really fit the task.

Tools: possibly not. Higher level encryption libraries are however certainly available, and libsodium has already been mentioned.

$\endgroup$
12
  • 1
    $\begingroup$ “It's not better or worse than any other AEAD cipher I suppose.” Note that OCB3 may be a patent quagmire. We don't know enough about OP's use case to rule that out as an issue. Military and contractors thereof require a license that may or may not be granted and/or expensive. $\endgroup$ – xorhash Aug 15 '20 at 5:48
  • $\begingroup$ @Maarten Bodewes What device would you store the private key on? A normal usb stick or something like that wouldn't be very secure right? $\endgroup$ – thebear8 Aug 15 '20 at 12:17
  • $\begingroup$ If you store it encrypted on the USB stick and only read it into memory then you can unplug it. Then an attacker that gains access to the (file) system can at least not reach it. So in that sense a normal USB stick can add security. It's basically about taking things offline. Note that even a USB stick may not hold the data forever (in the end it is a voltage difference within the flash cells after all), so without backup... $\endgroup$ – Maarten Bodewes Aug 15 '20 at 12:23
  • $\begingroup$ Hmm, that does make it more secure. I'll try to do that. I'll probably also use libsodium, as it makes the encryption a lot simpler. $\endgroup$ – thebear8 Aug 15 '20 at 15:26
  • $\begingroup$ Beware that you said that you may require a lot of decryptions to happen. If those are spaced far apart then you may need a different kind of key management. Automated decryption is unfortunately hard to secure, as you somehow need to make sure that only the correct party is calling the decryption procedure. $\endgroup$ – Maarten Bodewes Aug 15 '20 at 15:29

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.