4 ms·

AES on iOS isn't broken

20 points by hrbrmstr 15y ago

gwillen 15y ago
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 15y ago
  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 15y ago
    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.
- dlitz 15y ago
  Yes, the article is wrong, but ordinary developers shouldn't be using these low-level APIs anyway, unless they're implementing another, higher-level security protocols (such as OpenPGP, PKCS#5, PKCS#1, SSL, or SSH). I'm not familiar with iOS. Does Apple's SDK provide implementations of any of these higher-level protocols?
guan 15y ago
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?
- Robin_Message 15y ago
  It is XOR-ed with the first block to mask any pattern there, so a sequence is enough unless you think that the first blocks XOR-ed with a sequence might result in repeats, if for example they also contained a sequence. One obvious option that might work (I'm not a cryptography researcher, so ignore me) is that you could encrypt the sequenced IV to get a secure psuedo-random block.
- anologwintermut 15y ago
  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-cipher-block-chaining-cbc-attack-work-against-ssl/1082#1082 http://crypto.stackexchange.com/questions/1078/how-does-a-ci... for an explanation.
  - atonse 15y ago
    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 15y ago
      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 http://www.youtube.com/watch?v=BTqAIDVUvrU
agentultra 15y ago
It's not broken, but it is a poor default that is easily remedied.

20 points by hrbrmstr 15y ago

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 15y ago
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 15y ago
  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.
dlitz 15y ago
Yes, the article is wrong, but ordinary developers shouldn't be using these low-level APIs anyway, unless they're implementing another, higher-level security protocols (such as OpenPGP, PKCS#5, PKCS#1, SSL, or SSH). I'm not familiar with iOS. Does Apple's SDK provide implementations of any of these higher-level protocols?

guan 15y ago

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?

Robin_Message 15y ago
It is XOR-ed with the first block to mask any pattern there, so a sequence is enough unless you think that the first blocks XOR-ed with a sequence might result in repeats, if for example they also contained a sequence. One obvious option that might work (I'm not a cryptography researcher, so ignore me) is that you could encrypt the sequenced IV to get a secure psuedo-random block.
anologwintermut 15y ago
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-cipher-block-chaining-cbc-attack-work-against-ssl/1082#1082 http://crypto.stackexchange.com/questions/1078/how-does-a-ci... for an explanation.
- atonse 15y ago
  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 15y ago
    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 http://www.youtube.com/watch?v=BTqAIDVUvrU

agentultra 15y ago

It's not broken, but it is a poor default that is easily remedied.