

AES on iOS isn't broken - hrbrmstr
http://beechplane.wordpress.com/2011/12/14/aes-on-the-iphone-isnt-broken-by-default/

======
gwillen
This article is wrong. There are serious attacks against CBC with a zero IV. A
zero or re-used IV should not be used with CBC under any circumstances.

The author is correct that ECB is weaker than CBC with a zero IV. This is
because there are serious attacks against ECB, and ECB should not be used
under any circumstances.

(EDIT: I am not passing any judgement on Apple's choice of API defaults;
that's something people should feel free to argue about, and they will. I am
only pointing out that the author is mistaken to imply that using CBC with a
zero IV is safe or advised under any circumstances, which it is most assuredly
not.)

~~~
ComputerGuru
I saw the post as more of an attack against all those people saying that IVs
must not ever be made public.

You'd be surprised at who I've heard perpetuating these claims, ranging from
developers to cryptography professors at 2nd-tier universities. On that point,
the OP is spot on as _IVs are not meant to be secret_ their job is just to
prevent detection of patterns, i.e. seed randomizers in many ways.

And, yes, they shouldn't be reused. If they're being reused, they may as well
not be there.

~~~
atonse
Agreed. I'd also note that ECB, CBC, etc, have basically nothing to do with
the _algorithm_ being used (in this case, AES).

The idea of an IV, ECB, CBC, etc are just techniques to be used to make the
results of block ciphers more secure, regardless of what algorithm they use.

That's my bigger problem with the "AES is broken on iOS" claim based on IVs.
The two things are only loosely related.

------
guan
Question about IVs: is it enough that the IV is unique, or does it have to be
random? If I used a sequence that starts at 1 and is guaranteed to increment
for each message and never be reused, is that a good IV?

~~~
anologwintermut
It absolutely needs to be random. If not, the adversary can predict the IV and
use that to conduct either a chosen plaintext or ciphertext attack. This is
what happened to SSL a few months ago. See
[http://crypto.stackexchange.com/questions/1078/how-does-a-
ci...](http://crypto.stackexchange.com/questions/1078/how-does-a-cipher-block-
chaining-cbc-attack-work-against-ssl/1082#1082) for an explanation.

~~~
atonse
In a way, an IV is similar to the idea of the salt used in Hashes. It's
supposed to make it harder to find patterns in your ciphertext (or with a
hash, harder to generate the hash for every known character range you care
about).

So in that sense, just like it's good to have a different or random salt with
each hash, you'd want a differend (random) IV for each session.

~~~
dlitz
A salt is really just a nonce: It doesn't have to be random or unpredictable;
it just has to be globally unique so that attackers can't work to crack more
than one password at once (or pick out identical passwords given a list of
password hashes). We make it random because that's the only way we know how to
create globally-unique numbers in our decentralized network.

CBC-mode's IV really does need to be unpredictable by anyone who can influence
the plaintext. Otherwise, you get things like this:
<http://www.youtube.com/watch?v=BTqAIDVUvrU>

------
agentultra
It's not _broken_ , but it is a poor default that is easily remedied.

