Is this method of speeding up a symmetrical algorithm secure? (AES output joining) 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
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?