4

I have a few questions I'm stuck on for a cryptography course I'm doing, any help would be much appreciated.

The first application is for decryption on a multicore processor. I assume any of ECB, CBC, CFB or CTR would be suitable since decryption would be faster when performed in parallel, but are any of them significantly more suitable than the others and how?

The second is where it is preferred/desired to use a processor's idle time for precomputing encryption or decryption tasks before the plaintext or ciphertext is available. Not really sure how to tackle this one.

DavidR
  • 55
  • 1
  • 5
  • 1
    Tip: Only two of those modes can be encrypted and decrypted in parallel. One of those remaining two modes is typically unsuitable for use in general. – Stephen Touset Sep 10 '14 at 00:41
  • Ah okay so for the first part I'd need a mode with both parallel encryption and decryption so I see that CTR is a better choice than ECB. Would that also be the case for the second situation? The only other mode I've learned about is OFB but that has neither parallel encryption/decryption as well. – DavidR Sep 10 '14 at 01:03
  • You may want to re-review block cipher modes of operation. – Stephen Touset Sep 10 '14 at 02:23

2 Answers2

3

The first application is for decryption on a multicore processor. I assume any of ECB, CBC, CFB or CTR would be suitable since decryption would be faster when performed in parallel, but are any of them significantly more suitable than the others and how?

CTR, CBC and CFB all allow parallel decryption. CTR allows you to decrypt any ciphertext block independently, while the other two allow you to decrypt a block if you know the ciphertext of both it and the previous one.

However, of those only CTR also allows parallel encryption. ECB is insecure in most cases, so it shouldn't be used, but also supports both.

The second is where it is preferred/desired to use a processor's idle time for precomputing encryption or decryption tasks before the plaintext or ciphertext is available. Not really sure how to tackle this one.

Like ECB, both CBC and CFB require knowing the plaintext to compute any block encryptions (beyond the first block, in the case of CFB). CTR allows you to compute the entire keystream in advance.

However, in the real world you would most likely want to use authenticated encryption. Meaning you'd want to consider authenticated cipher modes as well. Many of them use CTR internally for the encryption part, fulfilling both of the above. GCM is the most common, and also allows the authentication part to be calculated in parallel.

otus
  • 32,132
  • 5
  • 70
  • 165
1

Counter mode is the only mode that fits both your use scenarios.

OFB and CTR are the 2 standard modes that convert the block cipher into a stream cipher, allowing precomputation of the key stream before plaintext or ciphertext is available, as well as allowing encryption without padding. CTR is the only one of these supporting parallel processing for both encryption and decryption (since to the block cipher it is the same operation).

CTR also allows searching at arbitrary block locations in the encrypted data stream, OFB/CFB require all previous blocks to be processed to get to a given block. This can dramatically reduce processing time if only a small part of the data requires decryption.

CTR of course requires a nonce to be secure, although that nonce does not need to be secret or unpredictable to an attacker.

Richie Frame
  • 13,097
  • 1
  • 25
  • 42