1
$\begingroup$

This is regarding the published paper on the DROWN attack (https://drownattack.com/drown-attack-original-report.pdf)

It was mentioned in the paper that for TLS, RSA PKCS#1 v1.5 is used to encapsulate the 48-byte premaster secret exchanged during the handshake. Does means that a random padding string PS is prepended to the 48-byte premaster secret to this formatted massage

([00] || [02] || PS || [00] || pms)

before the actual RSA encryption is done?

If yes, I have 2 questions

(1st question) How does the decryption oracle in the SSLv2 server differentiate between TLS-conformant ciphertexts and SSLv2-conformant ciphertexts, since the padded TLS plaintext also contains ([00]||[02]) as the 1st 2 bytes?

(2nd question) Why is it that one has to transform a RSA PKCS#1 v1.5 TLS conformant ciphertext to RSA PKCS#1 v1.5 SSLv2 conformant ciphertext before being fed to the Blechenbacher oracle?

Thanks in advance!

$\endgroup$
1
$\begingroup$

(background) It wasv mentioned in the paper that for TLS, RSA PKCS#1 v1.5 is used to encapsulate the 48-byte premaster secret exchanged during the handshake. Does means that a random padding string PS is prepended to the 48-byte premaster secret to this formatted massage
([00] || [02] || PS || [00] || pms)
before the actual RSA encryption is done?

Yes, with the correction that PS is random nonzero. (I'm sensitive to this because I once had to interop-test with a system that didn't correctly exclude zero from PKCS1-type2 padding, resulting in several percent of cryptograms causing spurious test failures.)

(1st question) How does the decryption oracle in the SSLv2 server differentiate between TLS-conformant ciphertexts and SSLv2-conformant ciphertexts, since the padded TLS plaintext also contains ([00]||[02]) as the 1st 2 bytes?

As described in 2.2, for SSLv2 the PKCS1-encrypted value is $mk_{secret}$ whose size depends on the ciphersuite selected.

As described in 3.2, the SSLv2 oracle (server) checks "$m$ starts with 0x00 02 followed by non-null padding bytes, a delimiter byte 0x00, and a master_key $mk_{secret}$ of correct byte length $k$" where k depends on the ciphersuite; examples given are 5 to 24.

48 is not equal to the k value for the selected SSLv2 ciphersuite, or indeed any of them.

3.3 confirms this: "But since no SSLv2 cipher suites have 48-byte key strengths, this means that a valid TLS ciphertext is invalid to our oracle O." The rest of 3.3 explains the (clever) process used to find a mathematically-related and SSLv2-conformant ciphertext.

(2nd question) Why is it that one has to transform a RSA PKCS#1 v1.5 TLS conformant ciphertext to RSA PKCS#1 v1.5 SSLv2 conformant ciphertext before being fed to the Blechenbacher oracle?

Because the SSLv2 oracle only gives a distinguishable response for an SSLv2-conformant ciphertext. For all TLS-valid ciphertexts it gives a randomized response from which no information can be extracted -- but the entire purpose of an oracle is to leak information.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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