Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
I am trying to set the iv to 8 bytes but every time I output the property, it keeps getting padded with zeros at the end. Is this expected and is it okay?
iv = @"c8accc2342fc8e11"; // 8 bytes
[crypt SetEncodedIV:iv encoding:@"hex"];
NSLog(@"IV: %@", crypt.IV); // IV: <c8accc23 42fc8e11 00000000 00000000>
This is OK. The length of the IV required is determined by the block size of the symmetric algorithm chosen. For example, AES, regardless of key size (128-bit, 192-bit, or 256-bit) has a 16-byte block size, and therefore the IV is always 16 bytes. The Blowfish encryption algorithm, on the other hand, uses an 8-byte block size. Regardless of the bit-strength of the Blowfish encryption, the block size is always 8 bytes and therefore the IV is 8 bytes.
There are no encryption algorithms (implemented by Chilkat) with a block size greater than 16 bytes. Therefore, the max IV would be 16 bytes. To ensure deterministic results, the IV provided by an application is always padded out to 16 bytes w/ NULL bytes. When encrypting/decrypting, only the 1st N bytes of the IV are used, where N is equal to the block size of the algorithm. Therefore, the extra NULL bytes are not used.
(The behavior might actually be this: When the IV is set by the application, the currently selected encryption algorithm is checked, and if not enough bytes are provided in the IV, then it is padded. For example, if the app first sets the IV, then sets the encryption algorithm, it may be that the default encryption algorithm (AES) required 16 bytes of IV, but then afterwards the encryption algorithm is set to Blowfish, which only requires 8 bytes. Reversing the order by setting the encryption algorithm first and then the IV might prevent the padding -- but it really doesn't matter because the padding won't hurt because the extra bytes aren't used.)