On Wed, 2018-05-02 at 10:01 +0200, F. E. wrote:
> "(Optional, but strongly recommended; PDF 1.1) An array of two byte-
> strings constituting a file identifier (see Section 10.3, “File
> Identifiers”) for the file. The two bytestrings should be direct
> objects and should be unencrypted. Although this entry is optional,
> its absence might prevent the file from functioning in some workflows
> that depend on files being uniquely identified."
>
> So Podofo is definitely doing something wrong there, since the ID
> bytestrings of a trailer are always decrypted, as far as I can see!
> With AESv2 encrpyted documents this wrong decryption does not cause
> errors, with AESv3 it does, it seems. Keep in mind that the latter
> document (with AESv3) is still not loadable even after the decryption
> of the ID is circumvented, there's might be something wrong in
> general with decrpytion of AESv3 encrypted documents.
Hi,
I've still this in a todo, even I hoped that someone more knowledgeable
would take over it, because my knowledge in this area is quite limited.
I also looked at the PDF specification and the section 7.6 contains the
information about Encryption, which seconds your findings in the 10.3
section you mentioned above. I believe it's PoDoFo doing things wrong,
because for example Evince (Poppler) can open the file without any
issue (or it masks it, though I kind of doubt it). Thus it can
eventually mean that the initial idea (the one before your improvement)
to not decrypt signature Contents hex-string was to workaround some
bigger issue in the background. It would be better to watch at it, I'm
afraid.
I'm, unfortunately, unable to investigate this into the deep and it's a
pita to have this lost in the mailing list, thus I'd like to ask for
help from anyone.
Thanks and bye,
zyx
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
