Re: Encrypted PDF isn't

[Richard Hector <richard@walnut.gen.nz>]

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