0
$\begingroup$

I was trying to find out a way of speeding up a given symmetrical algorithm the reason and programing launguage in this case are unimportant. I have came up with the following thing:

  • Divide data into n parts
  • Run n threads
  • Each thread encrypts its part of the data
  • Take the output of all of the threads and concatenate (join) all of them together

And for the decryption:

  • Divide the cipher text into the same parts that where joined
  • If feasible Run the same amount of threads as parts If not decrypt one after another
  • Join the outputs

Things that i can not do with my enviorment:

  • Change the algorithm code (I can only use encrypt and decrypt)

I am aware that i can use Electronic Code Book (ecb) for this goal but i would like it work for all modes.

My question is does the above method compromise security in any way? If it does. To what extend?

Sorry for making any mistakes this is my first question

$\endgroup$
5
  • 1
    $\begingroup$ I suspect that, unless the amount of data you're encrypting is huge, you won't gain much performance. Making things multithreaded has overhead, and that overhead can easily be much larger than the overhead inherent in encryption. $\endgroup$ – poncho Jun 5 '18 at 19:03
  • 1
    $\begingroup$ Additionally, multithreading may make it easier to lose track of where your keys are (which you'll want to erase after using them). Also, why not use counter-mode then? $\endgroup$ – VincBreaker Jun 5 '18 at 19:15
  • $\begingroup$ i was not thinking about a extreme number of threads if i can speed up the process even 2x its somenthing. Keys will be stored in protected memory and i hope that c# won't lose track of them and the algorithm is executed on a d/ced machine and in a trused enviorment. about counter mode the end user wants to use a few different modes (and there are multiple algorithms) but anyway thanks for the comments $\endgroup$ – nate2463 Jun 5 '18 at 19:27
  • $\begingroup$ Pretty important - if you have a piece of plaintext that you split into n chunks/threads, how many keys will you use to encrypt? $\endgroup$ – Paul Uszak Jun 6 '18 at 0:14
  • $\begingroup$ i was thinking about the same key for each chunk but some type of calculation to derive a new one for each thread can be an option $\endgroup$ – nate2463 Jun 6 '18 at 13:41
-1
$\begingroup$

The issues here are not so much security wise (that's downstream of this topic) but pragmatism. The penguin problem rules out ECB mode for most cipher use, so lets look at your requirements:-

Divide data into n parts

The easy bit

Run n threads

Not as easy as it sounds. This is very language dependent. For example Python doesn't do well with parallel tasks due to it's global interpreter locking system. Java threads can be cumbersome. And then there is the inter-thread communication - more overhead and slowdown. Even C/C++ threads will have to talk amongst themselves. Will you write a thread pool yourself? I guess there must be an extant library you could use as mitigation.

Each thread encrypts its part of the data

The crux of the cryptography. Have a close look through the wiki entry on cipher modes. You cannot hope to achieve parallel operation on all modes as that's fundamentally impossible for some as they're sequential. CBC mode is a simple example of one ciphertext passing into another subsequent block operation. Yes it can be run with multiple threads, but each thread will be paused waiting for the previous one in the chain to complete. That said, CTR mode seems to be a mode that's suitable for your scheme.

Take the output of all of the threads and concatenate (join) all of them together

Even in CTR mode the chunks have to come out in the correct order, requiring more thread collaboration. And again inter process communication has to be addressed which will siphon off speed gains.

So in conclusion, and without even dealing with specific security problems, this scheme is troublesome. Since only a few modes are possible in this scenario, and their security issues are mode dependent, it is quite difficult to give more detail. But just to mention a generic one, clones of the key and plaintexts will be floating around the machine that might open an attack vector. And the time of complete thread destruction can be uncertain under a garbage collector.

This falls into the realm of writing your own crypto, with key management, inter process communication and a large case of debugging. With modern CPUs featuring hardware AES circuity, that is clearly the way forward. I cannot think of any circumstance that warrants this level of cryptographic development, testing (heartache) and security risk. Remember that time is money if this is a commercial venture, and in that case does dubitable and possibly marginal performance gains offset just getting a faster CPU?

$\endgroup$
3
  • $\begingroup$ my launguage is C# Threading is managed and i trust the implementation in System.Threading; i am fully aware that what i am trying to do is basically ECB of X (But run in paraller) and i am also fully aware that some modes use the output of the previous block but that does not restrict me from using (Let's say) CTF but instead of each block being in seqence. its just a seqence of blocks that themselves are in seqence and about the cpu i've also thought about it before and tried it on a Pentium machine and on a i9 machine, speeds were in margin of error thats why threading is so important $\endgroup$ – nate2463 Jun 7 '18 at 5:15
  • $\begingroup$ @nate2463 If you have a sequence of sequences with a single key, they you'll probably need separate IVs or nonces. These will then have to be marshalled into order along with the ciphertext. $\endgroup$ – Paul Uszak Jun 7 '18 at 12:15
  • $\begingroup$ Probably better off asking on the main site, but I'd be surprised if native C# threading can handle the automatic complete of threads in a predefined sequence. CPUs are actually highly chaotic at the nano second level. $\endgroup$ – Paul Uszak Jun 7 '18 at 12:16

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.