Problem - Kevin Tafuro

In CBC, CFB, and OFB modes, encryption can’t really be parallelized because the
ciphertext for a block is necessary to create the ciphertext for the next block; thus,
we can’t compute ciphertext out of order. However, for CBC and CFB, when we
decrypt, things are different. Because we only need the ciphertext of a block to
decrypt the next block, we can decrypt the next block before we decrypt the first
one.
There are two reasonable strategies for parallelizing the work. When a message
shows up all at once, you might divide it roughly into equal parts and handle each
part separately. Alternatively, you can take an interleaved approach, where alternating
blocks are handled by different threads. That is, the actual message is separated
into two different plaintexts, as shown in Figure 5-5.
Original message M 1
1st plaintext
2nd plaintext
M 1
Figure 5-5. Encryption through interleaving
M 2
M 2
If done correctly, both approaches will result in the correct output. We generally prefer
the interleaving approach, because all threads can do work with just a little bit of
data available. This is particularly true in hardware, where buffers are small.
With a noninterleaving approach, you must wait at least until the length of the message
is known, which is often when all of the data is finally available. Then, if the
message length is known in advance, you must wait for a large percentage of the data
to show up before the second thread can be launched.
Even the interleaved approach is a lot easier when the size of the message is known
in advance because it makes it easier to get the message all in one place. If you need
the whole message to come in before you know the length, parallelization may not be
worthwhile, because in many cases, waiting for an entire message to come in before
beginning work can introduce enough latency to thwart the benefits of parallelization.
If you aren’t generally going to get an entire message all at once, but you are able to
determine the biggest message you might get, another reasonably easy approach is to
allocate a result buffer big enough to hold the largest possible message.
For the sake of simplicity, let’s assume that the message arrives all at once and you
might want to process a message with two parallel threads. The following code provides
an example API that can handle CTR mode encryption and decryption in parallel
(remember that encryption and decryption are the same operation in CTR mode).
Parallelizing Encryption and Decryption in Modes That Allow It (Without Breaking Compatibility) | 209
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
M 3
M 3
M 4
M 4
M 5
M 5