Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

According to RFC 4346

Explicit IVs

[CBCATT] describes a chosen plaintext attack on TLS that depends on knowing the IV for a record. Previous versions of TLS [TLS1.0] used the CBC residue of the previous record as the IV and therefore enabled this attack. This version uses an explicit IV in order to protect against this attack.

How are the IVs generated in concrete implementations? (like openSSL, BouncyCastle)

share|improve this question
    
The obvious implementation is requesting 16 bytes from the PRNG. –  CodesInChaos Oct 8 '13 at 16:43
    
Looking at the code written in BouncyCastle to create an explicit initialization vector used key block. (In constructor TlsBlockCipher) –  NiceTheo Oct 8 '13 at 18:04
add comment

1 Answer 1

up vote 3 down vote accepted

An implementation should generate the IV from any cryptographically secure PRNG. TLS 1.1 further details the possible ways to do that:

  • The IV can be obtained from a PRNG.
  • A random string $r$ can be generated from a PRNG, and added to the plaintext to encrypt where the IV should go; then the whole lot is encrypted with either a fixed IV, or even the last block of the previous record as IV. This method is easier to map on existing implementations of CBC encryption, because the IV is treated like plaintext. It is safe because $E(r \oplus iv)$, for a given $iv$ (e.g. the last block from the previous record) and encryption function $E$, is as uniformly random as $r$ itself.
  • The same method, but with $r$ being a fixed string.

It is unclear whether the third method is safe or not. It relies on the encryption $E$ to "act as a PRNG". The TLS 1.1 specification includes this:

 The following alternative procedure MAY be used; however, it has
  not been demonstrated to be as cryptographically strong as the
  above procedures.  The sender prepends a fixed block F to the
  plaintext (or, alternatively, a block generated with a weak PRNG).
  He then encrypts as in (2), above, using the CBC residue from the
  previous block as the mask for the prepended block.  Note that in
  this case the mask for the first record transmitted by the
  application (the Finished) MUST be generated using a
  cryptographically strong PRNG.

Since the specification gives it as a "MAY", one must assume that some implementers may have used this third method. Its advantage is that it does not require a PRNG invocation for every record, only for the first record, so a relatively slow PRNG can be tolerated.

Interestingly, all these detailed paragraphs have been removed from TLS 1.2, which merely states the generic "The Initialization Vector (IV) SHOULD be chosen at random, and MUST be unpredictable".

share|improve this answer
    
Real good answer.Can we use the same key material to form IV that is used to create encryption/decryption key in the TLS? –  NiceTheo Oct 8 '13 at 18:19
2  
Well you certainly can. In SSL 3.0 and TLS 1.0 it is done that way for the IV for the first encrypted record (the "master secret" is expanded into a "key block" which contains the encryption key, the MAC and the first IV for each direction of data transfer). However, each reuse of key material is, by nature, tricky, so there is room for failure here. –  Thomas Pornin Oct 8 '13 at 18:53
    
Thomas, I almost always agree with you, but I have no idea why you say "it is unclear whether the third method is safe" (presumbly using the last block of the previous record as the IV; obviously using a fixed IV has issues). It does assume that $E$ "acts as a PRNG", however CBC mode encryption itself essentially makes that assumption, so it seems like a safe assumption. It does leak an additional plaintext/ciphertext pair from the code-book for each message; given that the CBC-mode encryption of a known/guessable N block message already leaks N such pairs, leaking another is not intolerable –  poncho Oct 8 '13 at 19:29
    
I am just cautious since the author of RFC 4346 himself seemed to have some misgivings on the subject. It appears safe, for the reasons you state, but I don't want to carelessly give guarantees without doing some proper thinking time. –  Thomas Pornin Oct 8 '13 at 19:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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