2

Does anyone know how to set only the user password for qpdf encryption?

I'm using Debian 10 (buster) and qpdf version 8.4.2-1 from unstable backported to buster.

If I set just the user password (for example userpasswd), and leave the owner password blank (i.e. use the empty string ""), for some file foo.pdf, then the encryption command is just

qpdf --encrypt userpasswd "" 256 -- foo.pdf foo.enc.pdf

but okular, evince and xpdf all open foo.enc.pdf without asking for a password. If I use a password for both, I am asked for a password. I.e.

qpdf --encrypt userpasswd userpasswd 256 -- foo.pdf foo.enc.pdf

But I just want to do the user password encryption.

Also, pdfinfo reports that the file is encrypted.

pdfinfo foo.pdf
[...]
Encrypted:      yes (print:yes copy:yes change:yes addNotes:yes algorithm:AES-256)

It seems unlikely that something so simple is buggy, but I don't see what I'm doing wrong here.

Added an issue to QPDF's issue tracker on Github: Encrypting with just the user password

1

Punchline: most likely what you actually want to do is to use the empty string for the user password and a non-empty string for the owner password, not the other way around. If you do this, people will be able to open the file without supplying a password, but compliant viewers will still enforce the document's security. Opening with the owner password will allow you to modify security in a tool like Adobe Acrobat. Note that qpdf disregards the file's security in all cases and treats the user and owner passwords the same.

I'll try to explain what's going on.

Compliant PDF viewers are supposed to honor the file's security when the file is opened with the user password and allow full "admin" rights to the file when the file is opened with the owner password. As such, it doesn't make sense to provide a user password and not an owner password, as this would mean that providing a password is more restrictive than not providing a password.

In older PDF encryption formats, the file was encrypted by an encryption key that is derived from the user password, and the user password is actually stored in the file encrypted with the owner password. PDF viewers would first try to see if the supplied password is the user password. If so, they can retrieve the key and decrypt the file. If not, they check to see if it's the owner password. If so, they can retrieve the user password, and from there, they can retrieve the key. Newer encryption formats encrypt the actual key independently with both the user password and the owner password, and as such, it is not possible to retrieve the user password with the owner password.

Because of this behavior, some applications will try to open an encrypted password trying the empty string as the user password, and if that fails, they will prompt for a password. Some packages, including qpdf, will try to see if the owner password might be empty even when the user password is not empty, and even though this doesn't really make much sense. That would explain the behavior you are seeing. I believe that older versions of Adobe Acrobat will not allow admin access to the file at all if the user and owner password match or if the user password is set and the owner password is empty because they only attempt to validate the owner password if the supplied password doesn't work as the user password.

Hopefully this explains the behavior you are seeing.

|improve this answer|||||
  • 1
    All the explanation seems right, but the point was to encrypt the file, not add owner restrictions, so it sounds like (excepting older Acrobat) setting both to the same password will suffice. – Michael Homer Aug 18 '19 at 8:42

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.