CBC-MAC length extension attack with IV simulation I'm doing the Cryptopals challenges (formerly the Matasano challenges) and struggling with second part of the 49th problem where I'm asked to do the length extension attack with CBC-MAC without IV manipulation. There is a hint that I can simulate an IV somehow to do this but I don't understand. Can someone drop me some hint at least? I did the part with forging the first block of the message with changing the IV.

In particular there is a message format like this

  from=#{from_id}&amp;tx_list=#{transactions}


With the transaction list formatted like:

  to:amount(;to:amount)*


The task is: capture a valid message from target user. Use
length extension to add a transaction paying the attacker's account 1M
spacebucks.

EDIT
Alright, as I failed to explain it properly with my own words, here is the original problem

49. CBC-MAC Message Forgery

Let's talk about CBC-MAC.

CBC-MAC is like this:

  1. Take the plaintext P.
  2. Encrypt P under CBC with key K, yielding ciphertext C.
  3. Chuck all of C but the last block C[n].
  4. C[n] is the MAC.

Suppose there's an online banking application, and it carries out user
requests by talking to an API server over the network. Each request
looks like this:

  message || IV || MAC

The message looks like this:

  from=#{from_id}&amp;to=#{to_id}&amp;amount=#{amount}

Now, write an API server and a web frontend for it. (NOTE: No need to
get ambitious and write actual servers and web apps. Totally fine to
go lo-fi on this one.) The client and server should share a secret key
K to sign and verify messages.

The API server should accept messages, verify signatures, and carry
out each transaction if the MAC is valid. It's also publicly exposed -
the attacker can submit messages freely assuming he can forge the
right MAC.

The web client should allow the attacker to generate valid messages
for accounts he controls. (Feel free to sanitize params if you're
feeling anal-retentive.) Assume the attacker is in a position to
capture and inspect messages from the client to the API server.

One thing we haven't discussed is the IV. Assume the client generates
a per-message IV and sends it along with the MAC. That's how CBC
works, right?

Wrong.

For messages signed under CBC-MAC, an attacker-controlled IV is a
liability. Why? Because it yields full control over the first block of
the message.

Use this fact to generate a message transferring 1M spacebucks from a
target victim's account into your account.

I'll wait. Just let me know when you're done.

~ waiting ~

~ waiting ~

~ waiting ~

All done? Great - I knew you could do it!

Now let's tune up that protocol a little bit.

As we now know, you're supposed to use a fixed IV with CBC-MAC, so
let's do that. We'll set ours at 0 for simplicity. This means the IV
comes out of the protocol:

  message || MAC

Pretty simple, but we'll also adjust the message. For the purposes of
efficiency, the bank wants to be able to process multiple transactions
in a single request. So the message now looks like this:

  from=#{from_id}&amp;tx_list=#{transactions}

With the transaction list formatted like:

  to:amount(;to:amount)*

There's still a weakness here: the MAC is vulnerable to length
extension attacks. How?

Well, the output of CBC-MAC is a valid IV for a new message.

"But we don't control the IV anymore!"

With sufficient mastery of CBC, we can fake it.

Your mission: capture a valid message from your target user. Use
length extension to add a transaction paying the attacker's account 1M
spacebucks.

HINT:

  This would be a lot easier if you had full control over the first
  block of your message, huh? Maybe you can simulate that.

Food for thought:

  How would you modify the protocol to prevent this?
It seems that all this discussion about the IV is just to confuse the reader. Ignore IV. You just have to do a simple length-extension attack on the CBC-MAC. Yes, one message is enough.