0

For example: a 10 MB file will be sliced to 10 pieces (each 1 MB) and then dispersed between network nodes. Each node will encrypt it with its own key and different algorithm (AES, TwoFish, Blowfish, DES, 3DES, ... ).
(without using Rabin's ida or Shamir's secret sharing and so on).
Only slicing in a simple way and then encrypting with different key and algorithm. (Key size is not important).
Assuming that there is no resource limitation, would this be helpful? Does it increase security? Does it have equal security if encrypted it with one key and one algorithm without slicing? In this case: which one is more important, splitting data between nodes or different algorithms/keys?

  • 1
    It depends on the threat model. In general though, using multiple encryption algorithms next to each other makes the protection as weak as the weakest one. If an attacker can decrypt just 1 of your message pieces, they may already be able to do harm. – S.L. Barth Apr 29 '15 at 11:08
4

It depends what you're worried about, and what you are really trying to protect.

If each of these slices is individually important (say a 1 MB list of credit cards), then you're basically just encrypting each chunk by itself. The total strength of protection for each chunk is just the size of the key you used for that chunk (modulo strength/weakness of the algorithm used).
Regarding that last point - swapping around the encryption algorithms does not add any protection, you will still be only as strong (or as weak) as the algorithm you use for that chunk.

Likewise, if a breach of confidentiality of ANY CHUNK is gameover to you (i.e. the attacker only needs to break any one chunk, and once he does so he is not interested in the rest. E.g. a list of usable entry codes, the attacker only needs one) - then the total protection is the strength of the SHORTEST key used - and/or the WEAKEST algorithm of any of the nodes.
So unless all your nodes are using the same strong algorithm and the same keysize, you would be effectively weakening the solution.

On the other hand, if the only risk you are worried about is theft of ALL the chunks (e.g. even 9 out of 10 chunks stolen is not a threat) - then, assuming all the nodes are using the same strong algorithm (e.g. AES), the total protection achieved is the SUM of all the keysizes. (e.g. 10 x 256 bits).
In this specific scenario, it seems like you did achieve in overall improvement, since the attacker would need to brute force 10 keys of 256 bits, instead of just one.

However. Even if that was the case, you would achieve the same affect by just using a longer key, or cycling keys on the whole batch.
I won't even try to get into the mathy parts of cryptanalysis, if that would make it overall easier...

Since when it comes down to it, if you're using a proper strong algorithm, like AES, and a long enough key, brute force has already become irrelevant, so any possible increase in strength would be academic, with only a possible downside to this complicated solution. (At the very least, complexity is the last thing you want in your cryptosystem).

TL;DR:
Don't bother splitting it up.
In most cases it is directly worse.
In other cases, even if hypothetically there were any benefits, they would be irrelevant and come at a high cost.

  • thanks for reply, but if I use rabin's ida first and then encrypt each pieces with different keys is it worse again? – Ali Apr 29 '15 at 12:52
  • 1
    @Ali so as I understand Rabin's IDA (and I don't really...), this would effectively be similar to the 3rd scenario? I.e. attacker needs to break most of the chunks - how many depends on how the threshold is configured, but still would be most of them. So it seems to me that it is unlikely to be effectively better, as I explained, in which case you are worse off for the added cryptocomplexity with no benefit. – AviD Apr 29 '15 at 14:27

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.