2

I'm basically designing a protocol that requires a synchronous and ordered file transmission from a server (implemented in Node.js) to a device, over TCP. Streaming the file is not an option, so each file chunk is encapsulated in a message that has other non-encrypted fields, which are out of scope of this question.

One of the requirements is that the file contents can not be sent in plain text, so an encryption scheme had to be chosen, in this case I opted for the AES-256-CBC, assume for the purpose of this question that the algorithm can't be changed.

Due to device constraints (RAM ~10KB), it's required to split the file (<5 MB) into chunks, that will be then sent to the device according to the mentioned protocol, following a send / [ack|repeat] scheme. On reception, the device is able to store the chunk on disk.

So my main question here is that in the backend I have to choose between:

  • Encrypting the complete file and then split it into chunks

    -> On reception device would append each chunk in a file and then decrypt it when all chunks were received.

vs

  • Dividing the file into chunks and then encrypt each of them.

    -> Requires the sending of the Initialization Vector (IV) used on each chunk encryption in order to decrypt it.

    -> On chunk reception the device would have to decrypt the chunk or store each of them with the respective IV and then decrypt them after receiving the last chunk.

The goal here is to understand what security issues arise from each approach and also an overhead comparison between them.

PS: I also have an integrity validation scheme but is out of the question's ambit.

Improve this question
17
  • 1
    @SerDom: are you aware that you could encrypt, transmit and decrypt the data on the fly (CBC block by block), i.e. there is no need to encrypt the whole file first or split the file into chunks with separate encryption. And if you would use AES-GCM instead of AES-CBC this would also include integrity validation already.
    – Steffen Ullrich
    Commented May 24, 2018 at 13:14
  • Imagin for instance that the connection with device is lost, would it be posible, with the GCM aproach, on re-connection to continue the process from the previous state (before disconnection) @SteffenUllrich
    – domser
    Commented May 24, 2018 at 13:58
  • It does not matter if the underlying connection breaks or not since the encryption does not need to be bound to a specific connection (it just needs to keep some internal state). You only need to guarantee that the data arrive complete, in the correct order and without duplicates on the other side which you need to guarantee anyway. It does not matter how many connections you need to transfer the data to achieve this.
    – Steffen Ullrich
    Commented May 24, 2018 at 14:19
  • 1
    @SerDom Yes, getAuthTag is called on the encrypting end after encryption has finished, then the end decrypting calls setAuthTag just before finishing the decryption.
    – AndrolGenhald
    Commented May 24, 2018 at 16:37
  • 2
    @SerDom I don't follow. What's stopping you from doing while (more data) {update(); send();} final(); send(); getAuthTag(); send();, and on the receiving end while (more data) {receive(); update();} receive(); setAuthTag(); final();?
    – AndrolGenhald
    Commented May 24, 2018 at 16:56

1 Answer 1

Reset to default
3

Security wise, I don't see there is any difference.

Since integrity and availability are assumed to be handled properly, the only concern is confidentiality. Solution 1 uses only one IV, assuming you can generate good IVs (random and long enough), then that is fine. Solution 2 uses multiple IVs but they don't add more to security (IVs are all public). Indeed IVs are used to randomize ciphertext so that the chosen plaintext attack is not possible. One IV for the whole file is sufficient for this purpose. In solution 1 all data is encrypted under one key. This is the same in solution 2. Then confidentiality boils down to the security of this key. There is no difference in both solutions.

There might be some difference when it comes to performance. Solution 2 allows encryption and decryption to be done in parallel. This is not the case in solution 1. On the other hand, solution 2 requires slightly more space/computation/bandwidth due to the additional IVs.

Improve this answer
2
  • Thank you for your answer, as It goes straight to the main point discussed.
    – domser
    Commented May 24, 2018 at 16:34
  • Are there any references available discussing solution 2?
    – Darakian
    Commented Apr 8, 2020 at 17:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .