AES decryption with different IV

[Robert Bielik]

Ok, I'm confused. I'm encrypting a long string with a key + IV, then
when I decrypt with the same key, but different IV, shouldn't the
result be pretty much... garbage ? I'm getting back the same exact
string !(?)

[Walter Villalba]

What mode of operation are you using? Can you post a code snippet to
see how you're encrypting and decrypting ?

On Feb 24, 6:06 am, Robert Bielik <robert.bie...@modularstreams.com>
wrote:

[Robert Bielik]

On 25 Feb, 01:34, Walter Villalba <wvilla...@gmail.com> wrote:
> What mode of operation are you using?  Can you post a code snippet to
> see how you're encrypting and decrypting ?
>

I use CFB:


bool encryption::aes::writeEncryptedString( const char* key, const
char* iv, const std::string& plain, std::string& cipher )
{
CFB_Mode< AES >::Encryption e;
e.SetKeyWithIV((const byte*)key, AES::DEFAULT_KEYLENGTH, (const
byte*)iv);

// CFB mode must not use padding. Specifying
// a scheme will result in an exception
StringSource(plain, true,
new StreamTransformationFilter(e,
new Gzip(
new Base64Encoder(
new StringSink(cipher)
, false // No line breaks!
) // Base64Encoder
, CryptoPP::Deflator::MAX_DEFLATE_LEVEL
) // Gzip
) // StreamTransformationFilter
); // StringSource
return true;
}

bool encryption::aes::readEncryptedString( const char* key, const
char* iv, const std::string& cipher, std::string& plain )
{
CFB_Mode< AES >::Decryption d;
d.SetKeyWithIV((const byte*)key, AES::DEFAULT_KEYLENGTH, (const
byte*)iv);

// The StreamTransformationFilter removes
// padding as required.
StringSource s(cipher, true,
new Base64Decoder(
new Gunzip(
new StreamTransformationFilter(d,
new StringSink(plain)
) // StreamTransformationFilter
) // Gunzip
) // Base64Decoder
); // StringSource
return true;
}

/R

[User56784]

You are absolutely right that using random IV during encryption and
then another random IV during decryption will lead to garbage. What
you have to do is to send your random IV along with encrypted text.
Usually you put IV at the beginning. For example:
IV = 60ca
cipher = f576ab

you send
60caf576ab

For the decryption, you extract IV 60ca and use symetric key to
decrypt the rest of the string, in this case f576ab.

Why is it better to use random IV? Aren't we exposing it to potential
attacker if we send it along with the cipher text?
The answer is no. You could of course use static IV and make it secret
just like we keep the Key secret. However this would make encrypted
text weaker despite the fact that you keep both Key and IV secret.
Let's take an example:

secret Key = 123456
secret static IV = 4321

Now we encrypt some text:
Hello - gh78dj9dhjs8
How are you - vjsi574kjfjisre
Bye - mha8rjlsd8r3j
Hello - gh78dj9dhjs8

Everything looks fine, decryption works and we think we are safe. But
imagine you are a hacker. You try to do man-in-the-middle attack. You
will be listening on the line, collecting data and run analysis. After
a while you could notice that some texts is repeated. Also you have
different texts using the same Key and IV. Although it seems innocent
it can actually help in determining key. This type of encryption would
allow you to do some smart analysis and decrypt the message and
discover the key.
Let's see what it looks like when using randomly generated IV:

IV 7bc6
Hello - jskkj48t349h
Sending IV + text - 7bc6jskkj48t349h

IV 93d5
Hello - 834tns8of4af
Sending IV + text - 93d5834tns8of4af

IV 8fa9
How are you - kbmcj8234jdd
Sending IV + text - 8fa9kbmcj8234jdd

In this case it is true that attacker knows IV, it is the first 4
characters in the message, however it is not very useful, because in
first 2 messages the cipher is completely different despite the fact
that we are sending the same text. In case of let's say 16 byte IV, it
could take a long time before the same IV is generated and attacker
would need to listen much longer and collect much larger amounts of
data. Even if there is IV repeated after a while, 2 or 3 instances are
not enough to make deciphering the text and finding Key much easier.
To decipher the text it's probably just as hard as trying all
combinations of the key.
In case of static IV each message you send is useful for analysis as
IV is always the same.

Of course you could use static IV and keep it secret along with Key
where you don't have to encrypt to many messages. If you encrypt just
one text and you don't need to update it too often, attacker is left
with trying all combinations of the key. For network communication it
may be better to use randomly generated IV.
All depends on your application.

I hope this info will help you.


On Feb 25, 2:00 am, Robert Bielik <robert.bie...@modularstreams.com>
wrote:

[Robert Bielik]

On 26 Feb, 04:17, User56784 <r.ja...@comcast.net> wrote:
> You are absolutely right that using random IV during encryption and
> then another random IV during decryption will lead to garbage. What
> you have to do is to send your random IV along with encrypted text.
> Usually you put IV at the beginning. For example:
> IV = 60ca
> cipher = f576ab

>[...snip...]

Thanks for that message, however my point was that my decrypting with
another IV does _not_
produce garbage. In my application, the encrypted file is an XML and I
had hoped that the XML parsing
would fail due to the decrypted content being garbage, which is not
the case.

Should I use some other mode than CFB to make sure a different IV
leads to garbage?

Regards,
/Rob

[Elias Önal]

For CFB a wrong IV just corrupts the first block, thus that's normal
behavior.

On 2/28/11 8:50 AM, Jeffrey Walton wrote:
>
> On Feb 26, 9:12 am, Robert Bielik<robert.bie...@modularstreams.com>

> You should not depend on 'meaningful decryption' (or lack thereof) to
> determine if the cipher text is authentic, untampered, etc. From the
> HAC (p 364):
>
> A common misconception is that encryption provides data origin
> authentication and data integrity, under the argument that if a
> message
> is decrypted with a key shared only with party A, and the message
> is
> meaningful, then it must have originated from A.
>
> Also see http://www.cryptopp.com/wiki/Authenticated_encryption.
>
> Jeff
>

[Jeffrey Walton]

On Feb 25, 5:00 am, Robert Bielik <robert.bie...@modularstreams.com>
wrote:

Usually, it is preferred to compress before encrypting. Compression
will usually increase entropy of the message, which makes analysis
more difficult. Also, cipher text is typically not distinguishable
from random text, so the stream is usually not compressible.

Jeff

[Jeffrey Walton]

On Feb 26, 9:12 am, Robert Bielik <robert.bie...@modularstreams.com>
wrote:

[User56784]

I noticed you use CFB mode. I guess this only scrambles the first
block when decrypting with another IV. You should probably use CBC
mode. When you use CFB you get a little weaker encryption. When
changing one character in the text, CFB changes only one block in
cipher text. If you use CBC mode changing 1 character will generate
completely different cipher text, indistinguishable from random noise.
See pictures encrypted with CFB and CBC on
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation.

If you start using CBC mode you will also find that using different IV
for decryption than what was originally used for encryption will lead
to garbage. One small disadvantage of CBC is that you have to use text
that's multiple of block length. For example if you have text with
length of 123 chars, you need to add chars to have length 128 for
encryption. That may seem as not very convenient when comparing to
CFB, but it is actually an advantage, because it is harder to guess
length of the original text. I use multiple of 4096 chars for
encryption. text with length between 1 and 4096 chars will always have
cipher length 4096 chars. If you use it say for password, it is hard
to determine length of the password for brute force attack. If you
have XML file around 50 kB in size, the length for encryption will be
anywhere from 49152 B - 53248 B (multiple of 4096).


On Feb 26, 6:12 am, Robert Bielik <robert.bie...@modularstreams.com>
wrote:

[Robert Bielik]

> Usually, it is preferred to compress before encrypting. Compression
> will usually increase entropy of the message, which makes analysis
> more difficult. Also, cipher text is typically not distinguishable
> from random text, so the stream is usually not compressible.

Thanks! Funny, I thought I had it that way before... :)

/Rob

[Da Co]

Robert,

Thanks for bringing the attention on CTR mode.

The IV seems to be only useful for the first bloc, once the Key is known.

 

It seems to me that this is not a security issue, since the IV role is only to mask possible encryption paterns; as long as the key is not  known.

 

All, do you think it is a security issue?

 

 

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.

[Ken Rune Helland]

On 03/02/2011 06:23 PM, Da Co wrote:
> Robert,
> Thanks for bringing the attention on CTR mode.
> The IV seems to be only useful for the first bloc, once the Key is known.
>
> It seems to me that this is not a security issue, since the IV role is only to mask possible encryption paterns; as long as the key is not known.
>
> All, do you think it is a security issue?
>

A short comment.

For some crypto modes having a new random IV for each message
will cause each encrypted message to be unique even if the plaintext
is the same.

This denies Oscar the option to do analysis of rutine messages
that are the same with regular interwalls.

Best regards
Ken Rune