3
$\begingroup$

My software uses a 3rd party encryption appliance. One of the capabilities they allow is for the client software to supply an IV while doing CBC encryption.

Why would they not generate a random number on their own to use as an IV?

What is the advantage of letting the client specify an IV? I can only think of disadvantages, such as people supplying an insufficiently random number over a public network.

Improve this question
$\endgroup$
3
  • $\begingroup$ Could you specify the exact algorithm (cipher - e.g. AES - mode of operation - e.g. CBC - and padding - e.g. none of PKCS#7) for the appliance. This question is lacking information. $\endgroup$
    – Maarten Bodewes ♦
    Dec 28, 2014 at 3:40
  • $\begingroup$ Or just specify a link to the appliance of course, you've sparked my curiosity now. $\endgroup$
    – Maarten Bodewes ♦
    Dec 28, 2014 at 12:58
  • $\begingroup$ @MaartenBodewes-owlstead - I've updated the question with more information. $\endgroup$
    – OceanBlue
    Dec 29, 2014 at 16:02

2 Answers 2

Reset to default
4
$\begingroup$

There are many reasons why the IV could be expected as an input parameter:

  • it could be to let the user use his/her own random number generator, possibly because the device has none (as G_G has already stipulated)
  • it could be to allow for creating larger ciphertext (as ArtjomB has already mentioned) by using the IV to contain the last vector
  • it could be to let the user use a deterministic method instead of a random number generator (e.g. a random permutation of an encoded non-repeating counter for CBC or just a counter for CTR mode encryption)
  • it could be that the API doesn't allow for multiple return values, in that case the IV could be prefixed to the ciphertext, but the developer could have solved it by using the IV as parameter instead
  • it could be to keep the encryption/decryption calls symmetric (you need to specify the IV to the decryption routine somehow)
  • many protocols have specific requirements for the IV and it is a good idea to allow all possible protocols (this is basically the flexibility argument of ArtjomB with a specific reason)

It may also be that there is no specific reason at all. We cannot look into the minds of the engineer that created the device.

Supplying an IV over a public channel does not have to pose a problem, but it does raise questions about the security of the appliance.

Note that for chaining blocks in CBC it is required that the device does not pad the plaintext before encryption. If the intermediate plaintext is padded somehow then the result after concatenation would not be the same as the ciphertext that would result from a single call.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I'm sure there are more (e.g. for CTR encryption = decryption), but these seem to be the most common ones. None of them invalidate the idea of generating a random IV within the appliance, it may be a better solution than the separate IV. $\endgroup$
    – Maarten Bodewes ♦
    Dec 28, 2014 at 13:13
  • 1
    $\begingroup$ Another simple likelihood is that there are many cases where you need to perform encryption with a specific IV that's determined by part of the protocol, and can't be random. So an encryption appliance would need to provide APIs to support these types of use. $\endgroup$
    – Stephen Touset
    Apr 7, 2015 at 19:56
  • $\begingroup$ @StephenTouset Agreed and important enough to integrate into the answer, thanks for the additional argument! $\endgroup$
    – Maarten Bodewes ♦
    Apr 7, 2015 at 21:19
4
$\begingroup$

It offers more flexibility in using that API. Having a separate IV parameter enables bigger plaintexts than would not be possible in a single invocation, because of for example memory restrictions.

I assume CBC is used. You generate the IV and invoke the encryption on the first part of the big plaintext with the generated IV. For every other part of the plaintext, you take the last block of the previous ciphertext and use it as an IV to get the ciphertext of the current plaintext part. You then concatenate every ciphertext part to get a ciphertext which is the same as you would have got in a single invocation on the complete plaintext.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Artjom, thanks for taking the time to answer. Yes, CBC is used and I understand the role of an IV in CBC (which is exactly what you describe). What I don't understand is why the encryption service cannot generate a random number to use as its own IV in the CBC. What advantage is there is letting the client specify an IV? $\endgroup$
    – OceanBlue
    Dec 26, 2014 at 17:00
  • $\begingroup$ It could, but as I said, there may be some restrictions on how big plaintexts can be. Letting the user provide the IV, this limitation can be eliminated. This is good for the user. $\endgroup$
    – Artjom B.
    Dec 26, 2014 at 17:06
  • $\begingroup$ Wouldn't IV be dependent on the size of the BLOCK rather than size of the plaintext? (sorry for so many questions) $\endgroup$
    – OceanBlue
    Dec 26, 2014 at 17:13
  • 2
    $\begingroup$ @OceanBlue The point is, you split a large plaintext up into chunks. You don't want a random IV on the second chunk. You want to XOR the first block of the plaintext of the second chunk with the last block of ciphertext of the first chunk; that's exactly what would have happened if you were doing this in one invocation instead of chunking. To accomplish that, you must set the IV of the second chunk to the last ciphertext block of the first chunk. Think about how it would work if your function was limited to processing one block; that's exactly how you'd implement CBC. $\endgroup$
    – cpast
    Dec 26, 2014 at 20:37
  • 2
    $\begingroup$ One reason is because user may prefer another entropy source than the one shipped with the algorithm itself (If any). User got a super nice hardware rng and he/she want to use it. Another reason is that user wants to (or not want to) randomze the encryption algorithm (i.e. to output different chypertexts for the same plaintext) $\endgroup$
    – Gianluca Ghettini
    Dec 27, 2014 at 22:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.