I understand that BEAST is a CPA using javascript injected onto the browser's webpage. Apparently the thing that BEAST exploits is the fact that the IVs are predictable. What I'm confused about is why this is a problem when IVs are public anyway?

i'm looking at the first answer here: How can Cipher Block Chaining (CBC) in SSL be attacked? Aren't $IV_1$ and $IV_2$ public in TLS 1.2 as well? So why isn't BEAST allowed there? Is it because, when the malicious javascript encrypts messages for you, it uses a new, random IV each time (but not in TLS 1.0 or lower)? But doesn't this mean that BEAST will only verify you guessed a message correctly with quite low probability, and you only get one attempt for each message (because the IV keeps changing, even though it's predictable)?


1 Answer 1


Aren't $IV_1$ and $IV_2$ public in TLS 1.2 as well?

$IV_1$ certainly is (as that's just the ciphertext block in front of the block we're attacking); however the IV that the TLS 1.2 sender will use for the next message ($IV_2$) is not. In fact, the sender might not know it yet, as it might not have not picked it yet.

But doesn't this mean that BEAST will only verify you guessed a message correctly with quite low probability?

Actually, if you guess all 128 bits of the block correctly, it will tell you. If you say "what's the probability that we can guess all 128 bits?", well, we can make it significantly better than $2^{-128}$. Another thing that BEAST does is it maneuvers the cookie under attack so that the plaintext block that we're trying to guess consists of:


where it knows the first 15 bytes of the plaintext; all it needs to guess is the last byte of the plaintext (which is the first byte of the cookie under attack). Then, we need to check at worse 256 possibilities for that unknown byte (actually, less, because not all byte values are possible). Yes, each attack requires a new message; however messages are pretty cheap.

Then, if it finds out that the first byte is X, then it remaneuvers the cookie, and then it attacks a block that consists of:


where ? is the second byte of the cookie.

That's the insight of BEAST; not only does TLS 1.0 allow us to verify guessed plaintext blocks with a CPA attack, but also by playing games with cookies, we can make plaintext blocks guessable.

  • $\begingroup$ You say 'we only need to check 256 possibilities' but doesn't the IV change with each guess you make? And you only know the next IV for one guess, so don't you only get one attempt to guess a particular block? After that you need to wait for another message to be sent to be able to predict the next IV? $\endgroup$
    – Joe
    Jan 21, 2015 at 15:10
  • $\begingroup$ Actually, you don't need to wait for the browser to sent a genuine message do you, because you know what the IV will be of all messages (eg the messages you're making your java applet send)? The IVs won't be the same as the IVs the browser will genuinely use (as it isn't aware it's being attacked), but that doesn't matter for the purposes of your attack, right? $\endgroup$
    – Joe
    Jan 21, 2015 at 15:11
  • $\begingroup$ @JOe: that is correct -- you don't need to wait for the browser to send a message; we have the Java applet send messages when we want. $\endgroup$
    – poncho
    Jan 21, 2015 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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