I am using CTR mode to encrypt/decrypt files. Theoretically CTR mode is faster than CFB or CBC because of its individual operations on blocks. In my case CTR mode takes almost as long as CFB.
How can I attain/implement parallelization in CTR mode? Is it internally handled by the system?
Add a comment
|
1 Answer
In counter mode (CTR) no single block of cipher is dependent upon a previously calculated block. Each block can be calculated independently of every other block.
This could be parallelized by splitting the cipher into chunks for individual threads to encrypt or decrypt. Say you have a 512 byte block of data you want to encrypt. Using AES128-CTR there would be 32 blocks of data to encrypt (512/16). Say you want to use 4 threads. You would send 8 blocks to each thread with the nonce and counter range you want them to process.
As each thread finishes you need to piece the encrypted data bytes back together. So you'd have to ensure that you know which thread has finished, and where in the block of encrypted data you need to place it. Once all threads have returned, and you've pieced the data together you're done.
If this is performed already it would be at the implementation level. So if OpenSSL for example supports parallelization of CTR then it's possible. This might need to be configured (server-side) or you might have to feed it a parameter (client-side).
-
-
@Rak Look at the implementation. But I don't think it will be supported out of the box. Usually generic API's use some kind of streaming bytes or words into generic cipher classes. I've seen CTR implementations that allow seeking to a specific offset but parallelization would be much harder to achieve (and it would only work for rather large ciphertext to be available all at once if the streaming API is maintained). If you are smart you could reuse the existing CTR implementation to build the multithreading yourself though. Commented May 22, 2015 at 12:55
-
@Rak Upon looking into it further it seems most parallelized code is written for specific architectures and purposes. It'd be too difficult for something like OpenSSL to support parallelization across multiple architectures, and be stable.– RoraΖCommented May 22, 2015 at 13:29
-
@Raz But is it feasible to do it in application as you had explained?– RakCommented May 22, 2015 at 13:43
-
@Rak It's absolutely feasible as I've outlined it. You'd have to run some performance tests to see if it really gains you a significant improvement over just encrypting the entire block sequentially. The overhead of waiting for threads and piecing them back together might not be worth it.– RoraΖCommented May 22, 2015 at 13:44