# DROWN - decrypting ServerVerify message is not enough?

I have read this article, but I can't understand why after decrypting ServerVerify, the client needs to send the export grade PMS again...

When exploiting these flaws the attacker will send its candidate cipher-text to the server and receive the “ServerVerify” message. The attacker will then perform a brute-force search over all 2^40 possibilities for the export-grade PMS to find the PMS that derives a server session key that successfully decrypts the “ServerVerify” message. The attacker will know when a brute-force attempt is successful because the message will then decrypt into the random number he has previously chosen.

Having found the PMS of the first message the attacker then submits the same candidate cipher-text again and receives the “ServerVerify” message. He now uses the PMS found from the first message to derive the server session key for this second session. If this server session key successfully decrypts the “ServerVerify” message then the attacker knows that the server has arrived at the same PMS twice, turning the server into a Bleichenbacher oracle.

If the ServerVerify is decrypted successfully, the attacker will get the random number generated at the begining of the handshake. Is it not enough to confirm that the derived session key he has generated with his PMS is the correct one?

I already know that if after re-sending the same packet, the decrypted ServerVerify is the same, so the session key is the good one (acting like an oracle). But I don't think we need to do this step...

Is it a mistake?

No, it's not a mistake. After Bleichenbacher's attack was discovered, the fix throughout SSL/TLS was to prevent the "padding oracle" by decrypting and following this strategy: if the PKCS#1v1.5 padding is correct, then use the PMS obtained; if the PKCS#1v1.5 padding is incorrect, then use a random PMS. This prevents the oracle since an attacker who doesn't know the PMS cannot distinguish these two events (they are also supposed to take the same amount of time). However, in SSLv2, since it takes only $2^{40}$ to brute force the server reply, it's possible to re-establish the oracle. Specifically, the attacker gives the ciphertext twice to the server. If the padding is correct, then the server will reply with the same key both times. If the padding is incorrect, then since the server chooses a random key in this case, it will reply with different keys. This enables the attacker to know if the padding in the RSA encryption was correct or not.