How to generate a 128 bit IV from a 32 bit value for AES-128 OFB

I have no clue how to determine suitable 128 bit IV (initialization vector) from a 32 bit IV. Encryption AES-128 OFB. The 32 bit IV has value 0x9a23773c (transmitted in front of the data). Any ideas?

• Any reason that you don't just use the IV as is? Given that you're already 96 bits of entropy short against a determined actor, I'm not sure of any advantages IV expansion would give you. – Paul Uszak Nov 5 '19 at 11:40
• Although, an IV is meant to change. Therefore if you can make 32 bits of it, why can't you make 128 bits too? Err, it's not fixed is it? – Paul Uszak Nov 5 '19 at 11:42
• I know applied IV: 69e1f947 0e616d61 5fcf1917 4702398d. I'm looking for way to deploy 0x9a23773c to 0x69e1f947... – john_bigtower Nov 5 '19 at 11:54
• Are you asking for help with a specific protocol that you're trying to be compatible with? If so, what is the specific protocol? Or are you asking about how to use AES-OFB securely in a new protocol that you're designing? If so, why are you using AES-OFB and what are you doing about authentication and why don't you just use AES-GCM (or, better, NaCl crypto_secretbox_xsalsa20poly1305) instead? – Squeamish Ossifrage Nov 5 '19 at 16:44

OFB mode directly uses the IV as input to the block encryption - in this case by AES. So generally there is no 32 bit IV possible, it must be exactly the same size as the block size of the block cipher. OFB does not define any way to go from a 32 bit nonce to a 128 bit IV - if such an operation is defined then it is defined outside of the OFB definition in NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation.

Usually however the 32 bits are simply defined as leftmost bits of a 128 bit value, with zeros appended to the right hand side. Putting the values on the right hand side may also be a possibility however. Actually the bits can be put through any operation and put in any place as long as the result remains unique. But it seems unlikely that such an operation takes place at it would not have any function. Just try copy the bytes into the front or the back of a 128 / 8 = 16 bytes buffer and try if you guessed correctly.

Or ask the person that created the protocol of course, it never hurts to ask such a thing because they should have defined it for you.

• Unfortunately, i can't ask the person created the protocol. I suppose there must be a quick and easy conversion like MD5 or SHA. – john_bigtower Nov 5 '19 at 13:16
• Sure, those could work. MD5 would be logical as it outputs 128 bits and MD5 is often used by complete and utter idiots to create IV values from keys, just because they don't have another 128 bit value handy. So it is a good guess but yeah, you can only try. With SHA-1 and larger hashes usually the leftmost bits are used, but if you're handling an IV generated from a hash value then you'll have to expect the unexpected... – Maarten Bodewes Nov 5 '19 at 13:31

According to this survey of block cipher modes (pp. 30-37), OFB mode is not SemCPA secure if the IV is a nonce, but "secure with a fixed sequence of IVs, like a counter." This responds to a subtle nuance in this paper: the security model that Rogaway uses allows nonces to be selected by the adversary, so the attacks shown against nonce-based OFB rely on such adversarial control over nonces.

This means that as long as the application is 100% in control over the values of the nonces (such that an attacker can never influence them), then any method that uniquely extends 32-bit inputs to 128-bit outputs will work fine for extending IVs.

Important proviso: it's not safe to pick the 32-bit values randomly, the collision risk is very high, and for a stream cipher like OFB the consequence of nonce reuse is catastrophic. That also means the following statement had better refer to just one example message:

The 32 bit IV has value 0x9a23773c (transmitted in front of the data).