Adobe LiveCycle software supports password-based encryption using 40-bit or 128-bit RC4 encryption. Or, users can take advantage of certificate-based (PKI) encryption that uses up to 2,048-bit RSA encryption.
How are documents encrypted and decrypted?
Using APIs on the server, documents may be encrypted by either of the following methods:
Shared password protection: All recipients use a single password to open the document. Authors can optionally add a password that restricts the modification of permissions assigned to the rights of the document.
User-targeted encryption: Public key infrastructure (PKI) is used to assign unique access rights to each recipient, eliminating the need to create and distribute passwords to recipients.
When the recipient opens the file, either a password must be entered before the file is decrypted, or the file is decrypted automatically using the recipients private key. There are four encryption/decryption paths: server to server, server to desktop, desktop to server, and desktop to desktop.
The Adobe LiveCycle Document Security server product supports the following types of file encryption: 40bit RC4, 128bit RC4, 128bit AES. Files can be encrypted to open with a password or require a digital certificate.
Because PDF is an open specification, each developer creating PDF viewing software has the ability to support encrypted PDF files.
First of all, my recognition to Acrobat as one of the best sw ever.
We've using document compare since Acrobat 5.0, mainly to check for updates in text documents (digitally signed and password protected) between two different documents. The type of comparison we were using is textual differences.
Since Acrobat 7.0 we haven't been able to do that..... the only type of comparison working is "page by page" knowing this is not the best option when you deal with text documents (adding one page gives all pages as different)
When we try the "textual differences" we have this error:
"Acrobat.exe ha generado errores y será cerrado por Windows
Debe reiniciar el programa
My question is similar to the original question of can you decrypt by a non-Adobe app a secured PDF document that was encrypted by Adobe LiveCycle? Certainly if this decryption app has the password or the private key, it would be possible to decrypt. But are there any LiveCycle specific reasons why this workflow doesn't work. For example can such a decryption app get access through LiveCycle to the needed password or private key? I am trying to understand if such a workflow is possible.
For example of a workflow:
1) Use Acrobat and LiveCycle to create and store a secure PDF
2) Then extract secure PDF document from LiveCycle.
3) And is it also necessary to extract the needed data (password or private key to decrypt). Or is this managed outside of LiveCycle by the non Adobe decryption app?
I believe Lori is saying that the encryption in the resultant LiveCycle encrypted PDF is no different from what can be created from Acrobat, i.e. AES 128, 256, or RC4. Ive recently been looking specifically at Adobe's Java API for securing a PDF in LiveCycle. I would presume this usage of standard PDF language for encryption also applies to this LiveCycle programmatic API method to encrypt? And therefore If I did employ such a workflow of first interfacing with LiveCycle, performing one of the Java secure a PDF operations, I could then decrypt using non Adobe software and not be dependant on also using a similar LiveCycle Java Api call for decryption?
Sorry for so many questions, however I'm new to understanding LiveCycle and just trying to make sense of it.
A PDF might be encrypted using Acrobat (or also using the LC Server) using a password, Public Key Certificate or a symmetric key obtained from LC Rights Management for a policy protected document.
In all cases, LC needs its callers (through the SDK or in process design) to supply the secret used to yield the key for decryption. For example in order for LC to decrypt a password protected PDF, it requires the API caller to supply the actual password. LC does not have any internal means to decrypt a PDF without using the secret.
For Server based work flows, an encrypted PDF can be temporarily "unlocked" and decrypted in memory but that still requires the server to access the required secret. The Server has a "Trust Store" where you can upload private key credentials for this purpose (if the document is encrypted using a certificate). For Policy protected documents encrypted that were initially encrypted by the same server (which also maintains the symmetric keys) it is possible to unlock the PDF under a server side identity allowed in the policy. Password protected documents need the password to be supplied by the server side application.
The bottom line is that there is no special capability internal to Adobe's own software (LC and Acrobat) to decrypt content without the secret used by the party who encrypted the content.
Let me know if you have any other clarifications needed.