5.14. Parallelizing Encryption and Decryption in Arbitrary Modes (Breaking Compatibility)
Problem
You are using a cipher mode that is not intrinsically parallelizable, but you have a large data set and want to take advantage of multiple processors at your disposal.
Solution
Treat the data as multiple streams of interleaved data.
Discussion
Tip
Parallelizing encryption and decryption does not necessarily result in a speed improvement. To provide any chance of a speedup, you will certainly need to ensure that multiple processors are working in parallel. Even in such an environment, data sets may be too small to run faster when they are processed in parallel.
Recipe 5.13 demonstrates how to parallelize CTR mode encryption on a
per-block level using a single encryption context. Instead of having
spc_pctr_do_even( )
and spc_pctr_do_odd(
)
share a key and nonce, you could use two separate
encryption contexts. In such a case, there is no need to limit your
choice of mode to one that is intrinsically parallelizable. However,
note that you won’t get the same results when using
two separate contexts as you do when you use a single context, even
if you use the same key and IV or nonce (remembering that IV/nonce
reuse is a bad idea—and that certainly applies here).
One consideration is how much to interleave. There’s no need to interleave on a block level. For example, if you are using two parallel encryption contexts, you could encrypt the first 1,024 bytes of data with the first context, then alternate ...
Get Secure Programming Cookbook for C and C++ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.