On 25/02/16 18:23, David Wright wrote: > On Wed 24 Feb 2016 at 23:10:42 (+0000), Lisi Reisz wrote: >>> On Wednesday 24 February 2016 21:16:46 David Wright wrote: >>>>> encrypted.pdf >>> >>> No, sadly it is not! >>> >>> Sorry, David. ;-) > Well it turns out that the problem has affected other people, eg > http://superuser.com/questions/983368/both-pdftk-and-qpdf-fail-at-protecting-my-documents > > (still unanswered), but > https://en.wikipedia.org/wiki/Portable_Document_Format#Security_and_signatures > > knows the answer. You have to encrypt with > $ pdftk secret.pdf output /tmp/encrypted.pdf user_pw foo > > The man page for pdftk is therefore quite wrong when it says: > > Encrypt a PDF using 128-bit strength (the default), withhold all > permissions (the default) pdftk 1.pdf output 1.128.pdf owner_pw > foopass > > The owner_pw seems to be quite farcical when writing a pdf. > However, if you set both passwords (with different keys), giving > either key will decrypt it: > > $ pdftk secret.pdf output /tmp/encrypted.pdf user_pw foo owner_pw > bar $ pdftk /tmp/encrypted.pdf input_pw foo cat output > /tmp/u-used.pdf WARNING: The creator of the input PDF: > /tmp/encrypted.pdf has set an owner password (which is not required > to handle this PDF). You did not supply this password. Please > respect any copyright. $ pdftk /tmp/encrypted.pdf input_pw bar cat > output /tmp/o-used.pdf $ > > (Both /tmp/u-used.pdf and /tmp/o-used.pdf are decrypted.)
Not just the man page is wrong; if you add 'verbose' to the end of your original commandline, it will tell you clearly that the output will be encrypted (128 bit). Which of course it isn't. I take it you'll be filing a bug? Richard
