2

I have something of a theoretical question - how much of a cyber benefit would there be to taking data, breaking it up and encrypting it, then sending it to the destination via multiple disparate services and methods (such as part through an AWS cloud instance, part through Azure cloud instance, etc)? Would this be massively better than just encrypting it with standard AES-256-CBC/GCM and sending it as one stream of data?

Would this approach be a seriously rigorous way to improve secure data transmission, or is it not as good as it sounds to a layperson?

2
  • 1
    It would be helpful if you not only ask for the benefit of some theoretical idea but also share why you think there would even be a benefit in your opinion. You only state that it "sounds good to a layperson", implying that the perceived benefit should be obvious to others (i.e. no need to explain) but yet you still need to ask if the claimed but unexplained perceived benefit is actually real. Commented Jun 26 at 5:41
  • In practice, content encrypted with modern algorithms is stolen via attacks on the endpoints or users that store credentials to decrypt it, not on the data at rest. So this idea is doubling down on parts of the system that aren't actually subject to practical attack in the first place. Commented Jun 26 at 14:51

1 Answer 1

5

It depends on what exactly you want to protect from whom.

If the AES encryption is properly implemented, there are no practical attacks that would allow an attacker to obtain the plaintext from the ciphertext at rest without knowing the key. So if the purpose of splitting the files is to deal with some weakness of AES, then it's pointless, because such a weakness doesn't exist (as far as we know from publicly available information).

However, sending an encrypted file still generates a lot of metadata: The sender, the receiver and the (more or less) exact file size. You may not want to expose this metadata either (to your ISP, a government agency or whatever you have in mind). In this case, it makes sense to route parts of the file through different hosts instead of sending it to the receiver directly. However, instead of trying to come up with your own approach, use standard tools which were made for this exact purpose like Tor or at least a (cascaded) VPN.

9
  • Mind, routing through several services creates metadata (and opportunities for a subset of the ciphertext to be modified/corrupted by an attacker) in more places, and requires the sender and recipient to manage more credentials (and, in using them, exposing them to potentially be stolen via attacks on their client systems) so it's not a clear win even with that focus. Commented Jun 26 at 14:47
  • Ciphertext corruption can be easily detected with an AEAD mode like GCM or with a separate message authentication code, so this an implementation issue, not an inherent limitation of splitting the ciphertext.
    – Ja1024
    Commented Jun 26 at 14:54
  • Sure; detectable or not is beside the point; the point is that it's more attack points where an adversary can disrupt (or monitor metadata of) communications. Commented Jun 26 at 16:05
  • (one should also avoid overselling the ability to disrupt monitoring of metadata this way: it's only size being obscured, not timing or endpoints; and if an attacker knows from monitoring that the bucket they're able to monitor is 1/5th the size of the overall stream, then they can get the size while having only one out of 5 transfer points compromised) Commented Jun 26 at 16:10
  • Do you know how Tor works?
    – Ja1024
    Commented Jun 26 at 16:22

You must log in to answer this question.

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