In fact the whole algorithm is rather bizarre and doesn't instill much confidence in the security of password protected PDFs. Since the hash derivation uses only MD5 and RC4 (and not a lot of rounds of either) it is quite easy to try a lot of passwords in a short amount of time, so PDF is quite susceptible to brute force and dictionary attacks. What I would assume that John the Ripper does is it will feed passwords (defined by whatever rules you give it to generate passwords) into the above algorithm until it computes a user hash that matches the one in the document metadata (i.e.
(It's not clear why the user hash is padded at all, since the comparison to validate the user password throws out the padding bytes of the user hash and just looks at the first 16 bytes.) Append 16 bytes of arbitrary padding to the output of the last RC4 call.Take the output of the previous RC4 call and encrypt it under the new RC4 key.Create a new RC4 key by XORing every byte of the symmetric key from step 1 with i.Encrypt the output of the MD5 call via RC4 with the symmetric key from step 1.The 16 byte document ID (contained in the documents metadata).A 32 byte padding string (defined in the spec).
Concatenate the following values and pass the result to the MD5 hash function:.Derive the symmetric key from the user password.The process of producing the hash is as follows: PDF is strange in that it actually derives the symmetric key before it computes the hash, in fact the symmetric key is used in the computation of the hash. It will derive a hash from the password and will compare it to the user hash in the documents metadata to check if the password is correct.This is the key that the document is encrypted with. It will derive a symmetric key from the user password.A PDF will do two things when a password is entered for an encrypted PDF. Generally the target hash you want to break in the case of a PDF is the user hash, which is derived from the user's password.
0 kommentar(er)
