4
$\begingroup$

I've always known that the IV should be 128 bits, because that's the block size of AES, regardless of the key.

However, I just saw one vendor advertising AES-256 with a 256 bit IV.

Is there any point to that? Does a 'double' IV bring additional guarantees? For example, reducing the probability of having the same IV with the same key?

Will it even work with standard AES implementations, or they'll reject it? The Java implementation rejects it, for example.

Effectively, it adds another block of plaintext to throw away, but if it works, does it have negative effects (apart from having one more block to process)

Or is it just a marketing mistake...

$\endgroup$
  • $\begingroup$ @Bozho Why not point them out? If it is marketing material then it is supposed to be public, right? Then we can look at their claims. $\endgroup$ – Maarten Bodewes Jun 26 at 8:00
  • 1
    $\begingroup$ There you go bitglass.com/cloud-encryption :) $\endgroup$ – Bozho Jun 26 at 12:12
  • $\begingroup$ I didn't mention the mode because I don't know which one it is. I'd assume GCM or CBC, but who knows.. $\endgroup$ – Bozho Jun 26 at 12:14
  • 1
    $\begingroup$ Well, one can ask them as I did now. $\endgroup$ – kelalaka Jun 26 at 12:23
  • 5
    $\begingroup$ My snake oil detector goes all crazy multiple times on these two sentences: "(smurf) Cloud Encryption is patented, FIPS compliant 256-bit AES encryption with 256-bit initialization vectors. Only (smurf) provides industry standard, military grade encryption without compromising application functionality" ! I do not make that up ! $\endgroup$ – fgrieu Jun 26 at 16:22
9
$\begingroup$

I've always known that the IV should be 128 bits, because that's the block size of AES, regardless of the key.

The IV depends on the mode of operation. It may well be that the block mode of operation specifies to use the block size, but this is not a given. For instance, AES-GCM defaults to 96 bits.

For CTR mode it is rather common to supply an IV, but in reality that consists of a nonce and a starting counter value; you could have implementations / protocols that only expect the nonce as input, which would then be smaller than 128 bits.

However, I just saw one vendor advertising AES-256 with a 256 bit IV.

Not many modes support that, so I'm wondering how they accomplished that. AES-GCM does support it, but at the expense of additional calculations. Furthermore, it doesn't increase security at all. It doesn't make much sense for AES-CBC mode either, as the second ciphertext block will be the IV, i.e. the effective IV would still be 128 bits.

The other more likely option is that they use Rijndael with a block size of 256 bits. In that case it is not AES (which is Rijndael with a block size of 128 bits and only 3 key sizes with the default number of rounds configured). In that case they really don't know what they are doing.

Is there any point to that? Does a 'double' IV bring additional guarantees? For example, reducing the probability of having the same IV with the same key?

No generally it doesn't bring any benefits. As it is hard to use AES in such a way that the block size of 128 bits isn't a limiting factor (e.g. when it comes to processing a huge amount of blocks), I don't see how a larger IV would alleviate that issue.

Will it even work with standard AES implementations, or they'll reject it? The Java implementation rejects it, for example.

Again, it depends on the mode; GCM may grog it. Java simply keeps to the standards, I've not seen Oracle deviate all that much yet.

Effectively, it adds another block of plaintext to throw away, but if it works, does it have negative effects (apart from having one more block to process)

Again, depends on the mode and how it is configured.

Or is it just a marketing mistake...

I might well be a marketing mistake. That's pretty likely actually. An engineering mistake (AES vs Rijndael) is also likely. It could however also be snake oil although you should not attribute to malice that which is adequately explained by stupidity.

However, definitive statements can only be made after more detailed analysis, and for that we need the source. I'd have them explain it to you.

| improve this answer | |
$\endgroup$
  • $\begingroup$ "Very likely it is stupidity or snake oil, especially if it is explicitly marketed as such" - it could also be an inadvertent error, added by a marketing person who didn't understand the technology; if that were the case, the product might be quite sound (not claiming that it is, merely that it is a viable possibility) $\endgroup$ – poncho Jun 26 at 12:42
  • $\begingroup$ yeah, true, I should take the razor into account $\endgroup$ – Maarten Bodewes Jun 26 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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