Dynamic XOD encryption

[a a]

Hello.

I see that the converter to XOD allows for XOD encryption with AES 256.

https://groups.google.com/forum/#!msg/pdfnet-webviewer/KGDN8WqP1Ko/1-bG0PUsvc8J

Is there any way to encrypt the XOD files after its generation with a library of yours?

I need to do this dynamically when a user requests an XOD file.

Otherwise, I am thinking of using ZipDotNet (or sth similar) to encrypt with AES 256 the XOD file.

I just don't know yet:

1) If this ZIP would be compatible with your viewers (I have made some attempts but it seems the viewer doesn't like the encrypted ZIP or something goes wrong with the byte-range requests).

2) If this will affect performance in streaming mode (you have mentioned sth in a previous mail that the XOD is carefully crafted for performance, so I guess it will).

Also, can I make the HTML and Flash viewers to request the XOD file in just one piece? I need this because encrypting the XOD ZIP seems slow and, if I do it many times for a single file, it would be super-slow.

Thanks.

[Support]

Because we are applying AES in a different way (that is harder to crack compared to standard ZIP security), you would probably not be able to use a third party ZIP libs to encrypt the file.

Here are couple of alternatives:

a) Convert XOD to XOD (with AES)... using XPS to XOD conversion. This should run _much_ faster then conversion from PDF

b) Don't use our built-in encryption. Implement your own custom security hander (via a custom PartRetriever).

[a a]

And another question:

Does the Flash version of your viewer support encrypted XOD files?

[a a]

Hello.

I have an update for this issue.

I have encrypted an XOD file with ZipDotNet using AES 256 and I have tried to open it with PdfTron viewer (I have used the configuration of a sample of yours: http://www.pdftron.com/webviewer/demo/samples/encryption/config.js).

I got the following error in FireFox's console:

Error: Error loading document: Invalid XOD file: Zip end header data is wrong size!

The ZIP file opens correctly with WinRar and you can extract all the files from it (the password for it is: test).

Do you have any idea what is going on?

I give you my demo Visual Studio project : http://www.speedyshare.com/Xaxwa/PdfTronTestEcryption.zip

Thanks

[Matt Parizeau]

Hi,

Basically the AES encryption that is performed during the XOD conversion is more complicated then just encrypting the entire file. So as mentioned above you won't be able to use third party libraries to simply encrypt the entire file.

To summarize: If you want to use WebViewer's default AES decryption functionality then you must have converted the XOD file with the --xod_encrypt_password option (or equivalent for PDFNet and PWS).

If you want to encrypt the XOD with an outside library then you'll have to supply your own JavaScript function that can decrypt it. If you look in ReaderControl.js in the loadDocument function there is some commented out code the defines a custom decryption function. The custom decryption function is run for each part as necessary and is passed the data, decryptOptions and partName when it is called.

One thing to note is that if you use the default AES decryption then it is run in a web worker to improve performance, however a custom function will be run synchronously.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[a a]

Oh. I didn't get updates from Google Groups and I couldn't see your responses so far... :(

Sorry.

2014-05-19 11:40 GMT+03:00 a a <kouko...@gmail.com>:

Also, in your "WebViewer Developer Guide" you state:

 

Offline mode makes use of IndexedDB or WebSQL depending on the browser. It can also make use of the HTML5 application cache to allow for (re)loading of the page completely offline.

When the viewer is not in offline mode, where does it store the document? (after some tests I see that it writes somethings in IndexedDB, but I would like to know all possible cases)

I need to secure the documents that are viewed, so that the user cannot get them (at least without major hacks).

That's why I need to know where your viewer might save the document and if there is any case that is will save it there unencrypted while the server sends it encrypted.

( Also, I will need to make ZIP AES 256 encryption work with your viewer, since it doesn't seem to work so far. :( )

Thank you.

2014-05-16 18:03 GMT+03:00 a a <kouko...@gmail.com>:

Hi,

Are there any news on this issue?

Can I make this thing work?

Sorry for being impatient.

Also, another question I would like to ask is this:

When the file gets downloaded and stored in the browser's database (IndexedDB or WebSQL) for offline viewing, is it stored encrypted in there (in the browser's DB) or unencrypted?

Thank you.

[a a]

And another question that I forgot (sorry for bombarding you :D ):

In your documentation ("WebViewer Developer Guide.pdf") you state:

Documents are encrypted with 128 bit AES (Advanced Encryption Standard), a specification from the National Institute of Standards and Technology (NIST), and is used by governments and businesses worldwide.

But in a mailing list post, I saw that you've mentioned AES 256.

What kind of encryption does your ToXod() support? AES 128 or AES 256?

I guess it's AES 256, right?

Thanks.

2014-05-19 14:59 GMT+03:00 a a <kouko...@gmail.com>:

Also, another thing that I have noticed, that will certainly help some of your customers, is that -apparently- two encryptions of the same XOD file using the same password can (and do) produce different files.

I have not verified this 100%, but it is the most logical explanation to the behaviour that I see.

When the viewer requested byte-ranges from my controller action, I was watermarking and encrypting the the way you told me to (using XPS to XOD conversion) but the viewer displayed one or none pages correctly and then it showed an alert message "Invalid password of corrupt file.". Now that I cache the encrypted file in order to use it in all byte-range requests (and not re-build it from scratch), it seems that I see the encrypted document fine.

For a long time I thought that sth was wrong with my byte-range request library (which turns out to be very good by the way): https://mvcresumingactions.codeplex.com/

So, thank you and please don't forget to answer me concerning to :

1) Where the viewer save the document on each case and if it saves it encrypted there.

2) How can I avoid flushing my in-memory documents on disk to make the XPS to XOD conversion.

Thanks a lot and sorry for bugging you so much.

2014-05-19 12:08 GMT+03:00 a a <kouko...@gmail.com>:

And another question:

I don't seem to find any method that converts XPS to XOD that accepts the initial XPS/XOD file in memory.

Is there any?

I want to avoid flushing in-memory documents on disk to make the conversion.

The ToXod() only gets a PDFDoc or a file path as input file arguments.

Thank you.

[a a]

Also, in your "WebViewer Developer Guide" you state:

 

Offline mode makes use of IndexedDB or WebSQL depending on the browser. It can also make use of the HTML5 application cache to allow for (re)loading of the page completely offline.

When the viewer is not in offline mode, where does it store the document? (after some tests I see that it writes somethings in IndexedDB, but I would like to know all possible cases)

I need to secure the documents that are viewed, so that the user cannot get them (at least without major hacks).

That's why I need to know where your viewer might save the document and if there is any case that is will save it there unencrypted while the server sends it encrypted.

( Also, I will need to make ZIP AES 256 encryption work with your viewer, since it doesn't seem to work so far. :( )

Thank you.

2014-05-16 18:03 GMT+03:00 a a <kouko...@gmail.com>:

Hi,

Are there any news on this issue?

Can I make this thing work?

Sorry for being impatient.

Also, another question I would like to ask is this:

When the file gets downloaded and stored in the browser's database (IndexedDB or WebSQL) for offline viewing, is it stored encrypted in there (in the browser's DB) or unencrypted?

Thank you.

[a a]

Also, another thing that I have noticed, that will certainly help some of your customers, is that -apparently- two encryptions of the same XOD file using the same password can (and do) produce different files.

I have not verified this 100%, but it is the most logical explanation to the behaviour that I see.

When the viewer requested byte-ranges from my controller action, I was watermarking and encrypting the the way you told me to (using XPS to XOD conversion) but the viewer displayed one or none pages correctly and then it showed an alert message "Invalid password of corrupt file.". Now that I cache the encrypted file in order to use it in all byte-range requests (and not re-build it from scratch), it seems that I see the encrypted document fine.

For a long time I thought that sth was wrong with my byte-range request library (which turns out to be very good by the way): https://mvcresumingactions.codeplex.com/

So, thank you and please don't forget to answer me concerning to :

1) Where the viewer save the document on each case and if it saves it encrypted there.

2) How can I avoid flushing my in-memory documents on disk to make the XPS to XOD conversion.

Thanks a lot and sorry for bugging you so much.

2014-05-19 12:08 GMT+03:00 a a <kouko...@gmail.com>:

And another question:

I don't seem to find any method that converts XPS to XOD that accepts the initial XPS/XOD file in memory.

Is there any?

I want to avoid flushing in-memory documents on disk to make the conversion.

The ToXod() only gets a PDFDoc or a file path as input file arguments.

Thank you.

[a a]

And another question:

I don't seem to find any method that converts XPS to XOD that accepts the initial XPS/XOD file in memory.

Is there any?

I want to avoid flushing in-memory documents on disk to make the conversion.

The ToXod() only gets a PDFDoc or a file path as input file arguments.

Thank you.

[a a]

Hi,

Are there any news on this issue?

Can I make this thing work?

Sorry for being impatient.

Also, another question I would like to ask is this:

When the file gets downloaded and stored in the browser's database (IndexedDB or WebSQL) for offline viewing, is it stored encrypted in there (in the browser's DB) or unencrypted?

Thank you.

[Matt Parizeau]

Let's see if I can get all these questions answered! :)

ToXod uses AES128. We provide the decryption function for the default encryption function so you don't have to provide anything yourself. This link is just giving an example where you could use an external library to encrypt the file with AES256 and then you would provide your own decryption function to decrypt the parts of the document.

For non-offline mode: The document data is just stored in memory. We cache a number of parts for faster loading but like other caches the parts can be removed from the cache if new parts are loaded.

For offline mode: If the browser supports IndexedDB then the document data will be stored there, otherwise it will use WebSQL. The Application Cache is used for storing the other non-document resources (.html, .js, .css, etc) so that the viewer could be started up from a completely offline state. You can see the offline library sample for how to use the application cache.

The data that is stored in the offline database is not encrypted. This really isn't any different than if you hadn't stored it offline because someone who is determined enough could find the data since all the JavaScript code is running on the client side. Also the document is not stored in one large blob but instead separately as all of the "parts" of the file. So to be able to create a valid unencrypted XOD would still not be easy.

If you can consistently reproduce the converter generating different XOD files from the same inputs then you can send it our way. With the same input options the generated file should be the same so if that isn't the case then that's a bug.

To convert from XPS to XOD I believe you'll have to go through PDF. So you can use the FromXPS function to get a PDFDoc and then use the PDFDoc to convert to XOD.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[kouko...@gmail.com]

>> If you can consistently reproduce the converter generating different XOD files from the same inputs then you can send it our way. With the same input options the generated file should be the same so if that isn't the case then that's a bug.

I think this does happen and it is not a bug but the random padding of AES:

http://crypto.stackexchange.com/questions/12249/how-is-an-aes-encrypted-message-decrypted-with-random-padding

Thanks for all the info! :)