[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197129#comment-17197129 ] Tilman Hausherr edited comment on PDFBOX-4421 at 10/7/20, 4:16 PM: --- Encryption and decryption is there but IIRC length 128 doesn't work with external software. I don't have enough time right now, sadly. Maybe in a few days. Yes this is something you could try. I tried at that time and wasn't successful. The file I created at that time does have /V 4. But it's really the decryption that matters most. There is no real need to encrypt with 128, one should choose 256 (which works). was (Author: tilman): Encryption and decryption is there but IIRC length 128 doesn't work with external software. [Code|https://kb.itextpdf.com/home/it7kb/examples/certificate-encryption] that I used to create an encrypted PDF to try decryption (at that time, I used itext 7.1.3 + bc 1.60). I don't have enough time right now, sadly. Maybe in a few days. Yes this is something you could try. I tried at that time and wasn't successful. The file I created at that time does have /V 4. But it's really the decryption that matters most. There is no real need to encrypt with 128, one should choose 256 (which works). > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208259#comment-17208259 ] Tilman Hausherr edited comment on PDFBOX-4421 at 10/5/20, 6:59 PM: --- Need to do some housekeeping before resolving, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. Also, keyStore parameter null is reported as "Provided decryption material is not compatible with the document" which is 臘♂️ was (Author: tilman): Need to do some housekeeping before resolving, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208259#comment-17208259 ] Tilman Hausherr edited comment on PDFBOX-4421 at 10/5/20, 6:57 PM: --- Need to do some housekeeping before resolving, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. was (Author: tilman): Need to do some housekeeping, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207888#comment-17207888 ] Christian Appl edited comment on PDFBOX-4421 at 10/5/20, 8:06 AM: -- Sure! "AESkeylength128.pdf" and "AESkeylength256.pdf" should both be using certificates from the "keystore.pfx" I already shared. alias: testnutzer password: w!z%C*F-JaNdRgUk The used Software is the current Adobe Acrobat Pro DC if you want to check whether you can use those PDFs. was (Author: capsvd): Sure! "AESkeylength128.pdf" and "AESkeylength256.pdf" should both be using certificates from the "keystore.pfx" I already shared. alias: testnutzer password: w!z%C*F-JaNdRgUk > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198723#comment-17198723 ] Tilman Hausherr edited comment on PDFBOX-4421 at 9/19/20, 12:59 PM: I wanted to add small files created with itext but after reading their license, I realize I can't, even if I'd publish the source code, because it may not be used in a "non AGPL environment". [~capSVD] when back, could you please create two very small files with the software you used, only with one page, and the text "Key length: 128" and "Key length: 256". Your two files are too large because I'd like to include them in the source distribution as part of a test. was (Author: tilman): I wanted to add small files created with itext but after reading their license, I realize I can't, even if I'd publish the source code, because it may not be used in a "non AGPL environment". [~capSVD] when back, could you please create two very small files with the software you used, only with one page, and the text "Key length: 128" and "Key length: 256". Your two files are too large because I'd like to include them in the source distribution. > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 3.0.0 PDFBox, 2.0.22 > > Attachments: B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198385#comment-17198385
]
Tilman Hausherr edited comment on PDFBOX-4421 at 9/18/20, 3:00 PM:
---
I assume this patch is against the version before I made my changes, because it
gets refused ("Cannot apply hunk"). However both of your files get opened and
read with the current code. But don't worry, when it's all done I'll also have
two test files created not with PDFBox to make sure that the code is good with
files without the length entry.
was (Author: tilman):
I assume this patch is against the version before I made my changes, because it
gets refused ("Cannot apply hunk"). However both of your files get opened and
read with the current code. But don't worry, when it's all done I'll also have
two test files created not with PDFBox to make sure that the test is good.
> Add support for AES128 encryption for public key
>
>
> Key: PDFBOX-4421
> URL: https://issues.apache.org/jira/browse/PDFBOX-4421
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: AES128
> Fix For: 3.0.0 PDFBox, 2.0.22
>
> Attachments: B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf,
> PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch,
> PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch,
> image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png,
> image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png
>
>
> Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128
> doesn't when the file is generated by an external software. (local tests
> work) We should at least get the decryption to work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198359#comment-17198359 ] Christian Appl edited comment on PDFBOX-4421 at 9/18/20, 2:12 PM: -- *Concerning AES-256:* I won't have the time to further check and verify this, as I will be on vacation for the next 2 weeks, but: I also stumbled upon the keylength problem for AES-256. For AES-128 and AES-256 Adobe DC apparently never sets the optional /Length entry for the encryption dictionary - possibly AES-256 should also rather search the Filters for such a length entry additionally. As pointed out above: Otherwise it will attempt to use the default value (40) and will fail to decrypt documents for that reason: !screenshot-1.png! Also see: B2-AES-256-secured.pdf for an example *Edit:* Updated patch has been provided - this should fix it, but should be tested. was (Author: capsvd): *Concerning AES-256:* I won't have the time to further check and verify this, as I will be on vacation for the next 2 weeks, but: I also stumbled upon the keylength problem for AES-256. For AES-128 and AES-256 Adobe DC apparently never sets the optional /Length entry for the encryption dictionary - possibly AES-256 should also rather search the Filters for such a length entry additionally. As pointed out above: Otherwise it will attempt to use the default value (40) and will fail to decrypt documents for that reason: !screenshot-1.png! Also see: B2-AES-256-secured.pdf for an example > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 3.0.0 PDFBox, 2.0.22 > > Attachments: B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197520#comment-17197520
]
Christian Appl edited comment on PDFBOX-4421 at 9/17/20, 10:37 AM:
---
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
won't brake for some cases, but your thoughts about it would be absolutely
helpful!)
*Basic Assumption:*
This should work! I can find the parts of the Reference manual, that are
represented here and I can't find big definition gaps at first glance.
*1. Assumption: The assumed key length is wrong (40 instead of 128):*
The method "prepareForDecryption" in PublicKeySecurityHandler is currently
determining the key length via the PDEncryption dictionary
encryption.getLength(). for the case +if (encryption.getVersion() == 4 ||
encryption.getVersion() == 5)+ possibly it should be modified like:
{code:java}
// detect whether AES encryption is used. This assumes that the encryption algo
is
// stored in the PDCryptFilterDictionary
// However, crypt filters are used only when V is 4 or 5.
PDCryptFilterDictionary defaultCryptFilterDictionary =
encryption.getDefaultCryptFilterDictionary();
if (defaultCryptFilterDictionary != null) {
if (defaultCryptFilterDictionary.getLength() != 0) {
setKeyLength(defaultCryptFilterDictionary.getLength());
}
}
{code}
*2. Assumption: Now that it accepts, that the key length is 128, the message
digest is wrong.*
For my test document it now succeeded in creating the cipher, but reported a
wrong padding / a wrong key, when trying doFinal(). I was absolutely certain to
provide the corrrect password, alias and keystore to a matching document,
therefore: The message digest - determining the key - can not be correct. I
found this:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA256().digest(sha1Input);
{code}
And simply changed it to:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA1().digest(sha1Input);
{code}
A change which will most definately brake the AES256 handling, but I ignored
that for now. (possibly V4 and V5 should be handled in separate cases for this
reason?
*Could these assumptions be possibly correct?*
I created a AES128 encrypted document using Adobe DC and wrote a most
simplistic test, that shall load said document using my testkeystore and shall
determine the number of pages:
{code:java}
private static final String password = "w!z%C*F-JaNdRgUk";
private static final String alias = "testnutzer";
@Test
public void openEncDoc() throws Exception {
File keystore = new File("C:\\Users\\cap.SVD\\Desktop", "keystore.pfx");
File encDoc = new File("C:\\Users\\cap.SVD\\Desktop",
"B2-Adobe-128-aes-sec.pdf");
System.out.println("Now loading and decrypting: " +
encDoc.getAbsolutePath());
InputStream keyStoreData = new FileInputStream(keystore);
PDDocument doc = PDDocument.load(encDoc, password, keyStoreData, alias);
try {
System.out.println(" SUCCESS decrypting document, it has " +
doc.getNumberOfPages() + " pages.");
} finally {
keyStoreData.close();
doc.close();
}
}
{code}
Which failed previously for said document and now results in the output:
Now loading and decrypting: C:\Users\cap.SVD\Desktop\B2-Adobe-128-aes-sec.pdf
SUCCESS decrypting document, it has 3 pages.
-The document has been successfully decrypted and the number of pages could be
determined?
I really don't trust myself here, therefore:
- Where am I seeing things too simple or could this possibly be the solution?
I will definately follow this lead for now - as it resulted in a success - but
I don't trust that success yet neither, further testing is required and this is
for now quick and dirty trash code, to simply make it work (somehow).
*Edit:*
Applying the same assumptions to "prepareDocumentForEncryption" also resulted
in a AES128 encrypted document, that could be opened by Adobe DC and still
contained everything it shall contain (or so it seems).
{code:java}
if (version == 4)
{
dictionary.setSubFilter(SUBFILTER5);
mdResult = MessageDigests.getSHA1().digest(shaInput);
COSName aesVName = COSName.AESV2;
prepareEncryptionDictAES(dictionary, aesVName, recipientsFields);
} else if(version == 5) {
dictionary.setSubFilter(SUBFILTER5);
mdResult =
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197520#comment-17197520
]
Christian Appl edited comment on PDFBOX-4421 at 9/17/20, 10:30 AM:
---
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
won't brake for some cases, but your thoughts about it would be absolutely
helpful!)
*Basic Assumption:*
This should work! I can find the parts of the Reference manual, that are
represented here and I can't find big definition gaps at first glance.
*1. Assumption: The assumed key length is wrong (40 instead of 128):*
The method "prepareForDecryption" in PublicKeySecurityHandler is currently
determining the key length via the PDEncryption dictionary
encryption.getLength(). for the case +if (encryption.getVersion() == 4 ||
encryption.getVersion() == 5)+ possibly it should be modified like:
{code:java}
// detect whether AES encryption is used. This assumes that the encryption algo
is
// stored in the PDCryptFilterDictionary
// However, crypt filters are used only when V is 4 or 5.
PDCryptFilterDictionary defaultCryptFilterDictionary =
encryption.getDefaultCryptFilterDictionary();
if (defaultCryptFilterDictionary != null) {
if (defaultCryptFilterDictionary.getLength() != 0) {
setKeyLength(defaultCryptFilterDictionary.getLength());
}
}
{code}
*2. Assumption: Now that it accepts, that the key length is 128, the message
digest is wrong.*
For my test document it now succeeded in creating the cipher, but reported a
wrong padding / a wrong key, when trying doFinal(). I was absolutely certain to
provide the corrrect password, alias and keystore to a matching document,
therefore: The message digest - determining the key - can not be correct. I
found this:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA256().digest(sha1Input);
{code}
And simply changed it to:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA1().digest(sha1Input);
{code}
A change which will most definately brake the AES256 handling, but I ignored
that for now. (possibly V4 and V5 should be handled in separate cases for this
reason?
*Could these assumptions be possibly correct?*
I created a AES128 encrypted document using Adobe DC and wrote a most
simplistic test, that shall load said document using my testkeystore and shall
determine the number of pages:
{code:java}
private static final String password = "w!z%C*F-JaNdRgUk";
private static final String alias = "testnutzer";
@Test
public void openEncDoc() throws Exception {
File keystore = new File("C:\\Users\\cap.SVD\\Desktop", "keystore.pfx");
File encDoc = new File("C:\\Users\\cap.SVD\\Desktop",
"B2-Adobe-128-aes-sec.pdf");
System.out.println("Now loading and decrypting: " +
encDoc.getAbsolutePath());
InputStream keyStoreData = new FileInputStream(keystore);
PDDocument doc = PDDocument.load(encDoc, password, keyStoreData, alias);
try {
System.out.println(" SUCCESS decrypting document, it has " +
doc.getNumberOfPages() + " pages.");
} finally {
keyStoreData.close();
doc.close();
}
}
{code}
Which failed previously for said document and now results in the output:
Now loading and decrypting: C:\Users\cap.SVD\Desktop\B2-Adobe-128-aes-sec.pdf
SUCCESS decrypting document, it has 3 pages.
-The document has been successfully decrypted and the number of pages could be
determined?
I really don't trust myself here, therefore:
- Where am I seeing things too simple or could this possibly be the solution?
I will definately follow this lead for now - as it resulted in a success - but
I don't trust that success yet neither, further testing is required and this is
for now quick and dirty trash code, to simply make it work (somehow).
*Edit:*
Applying the same assumptions to "prepareDocumentForEncryption" also resulted
in a AES128 encrypted document, that could be opened by Adobe DC and still
contained everything it shall contain (or so it seems).
{code:java}
if (version == 4)
{
dictionary.setSubFilter(SUBFILTER5);
mdResult = MessageDigests.getSHA1().digest(shaInput);
COSName aesVName = COSName.AESV2;
prepareEncryptionDictAES(dictionary, aesVName, recipientsFields);
} else if(version == 5) {
dictionary.setSubFilter(SUBFILTER5);
mdResult =
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197520#comment-17197520
]
Christian Appl edited comment on PDFBOX-4421 at 9/17/20, 10:29 AM:
---
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
won't brake for some cases, but your thoughts about it would be absolutely
helpful!)
*Basic Assumption:*
This should work! I can find the parts of the Reference manual, that are
represented here and I can't find big definition gaps at first glance.
*1. Assumption: The assumed key length is wrong (40 instead of 128):*
The method "prepareForDecryption" in PublicKeySecurityHandler is currently
determining the key length via the PDEncryption dictionary
encryption.getLength(). for the case +if (encryption.getVersion() == 4 ||
encryption.getVersion() == 5)+ possibly it should be modified like:
{code:java}
// detect whether AES encryption is used. This assumes that the encryption algo
is
// stored in the PDCryptFilterDictionary
// However, crypt filters are used only when V is 4 or 5.
PDCryptFilterDictionary defaultCryptFilterDictionary =
encryption.getDefaultCryptFilterDictionary();
if (defaultCryptFilterDictionary != null) {
if (defaultCryptFilterDictionary.getLength() != 0) {
setKeyLength(defaultCryptFilterDictionary.getLength());
}
}
{code}
*2. Assumption: Now that it accepts, that the key length is 128, the message
digest is wrong.*
For my test document it now succeeded in creating the cipher, but reported a
wrong padding / a wrong key, when trying doFinal(). I was absolutely certain to
provide the corrrect password, alias and keystore to a matching document,
therefore: The message digest - determining the key - can not be correct. I
found this:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA256().digest(sha1Input);
{code}
And simply changed it to:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA1().digest(sha1Input);
{code}
A change which will most definately brake the AES256 handling, but I ignored
that for now. (possibly V4 and V5 should be handled in separate cases for this
reason?
*Could these assumptions be possibly correct?*
I created a AES128 encrypted document using Adobe DC and wrote a most
simplistic test, that shall load said document using my testkeystore and shall
determine the number of pages:
{code:java}
private static final String password = "w!z%C*F-JaNdRgUk";
private static final String alias = "testnutzer";
@Test
public void openEncDoc() throws Exception {
File keystore = new File("C:\\Users\\cap.SVD\\Desktop", "keystore.pfx");
File encDoc = new File("C:\\Users\\cap.SVD\\Desktop",
"B2-Adobe-128-aes-sec.pdf");
System.out.println("Now loading and decrypting: " +
encDoc.getAbsolutePath());
InputStream keyStoreData = new FileInputStream(keystore);
PDDocument doc = PDDocument.load(encDoc, password, keyStoreData, alias);
try {
System.out.println(" SUCCESS decrypting document, it has " +
doc.getNumberOfPages() + " pages.");
} finally {
keyStoreData.close();
doc.close();
}
}
{code}
Which failed previously for said document and now results in the output:
Now loading and decrypting: C:\Users\cap.SVD\Desktop\B2-Adobe-128-aes-sec.pdf
SUCCESS decrypting document, it has 3 pages.
-The document has been successfully decrypted and the number of pages could be
determined?
I really don't trust myself here, therefore:
- Where am I seeing things too simple or could this possibly be the solution?
I will definately follow this lead for now - as it resulted in a success - but
I don't trust that success yet neither, further testing is required and this is
for now quick and dirty trash code, to simply make it work (somehow).
*Edit:*
Applying the same assumptions to "prepareDocumentForEncryption" also resulted
in a AES128 encrypted document, that could be opened by Adobe DC and still
contained everything it shall contain (or so it seems).
{code:java}
if (version == 4)
{
dictionary.setSubFilter(SUBFILTER5);
mdResult = MessageDigests.getSHA1().digest(shaInput);
COSName aesVName = COSName.AESV2;
prepareEncryptionDictAES(dictionary, aesVName, recipientsFields);
} else if(version == 5) {
dictionary.setSubFilter(SUBFILTER5);
mdResult =
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197520#comment-17197520
]
Christian Appl edited comment on PDFBOX-4421 at 9/17/20, 10:01 AM:
---
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
won't brake for some cases, but your thoughts about it would be absolutely
helpful!)
*Basic Assumption:*
This should work! I can find the parts of the Reference manual, that are
represented here and I can't find big definition gaps at first glance.
*1. Assumption: The assumed key length is wrong (40 instead of 128):*
The method "prepareForDecryption" in PublicKeySecurityHandler is currently
determining the key length via the PDEncryption dictionary
encryption.getLength(). for the case +if (encryption.getVersion() == 4 ||
encryption.getVersion() == 5)+ possibly it should be modified like:
{code:java}
// detect whether AES encryption is used. This assumes that the encryption algo
is
// stored in the PDCryptFilterDictionary
// However, crypt filters are used only when V is 4 or 5.
PDCryptFilterDictionary defaultCryptFilterDictionary =
encryption.getDefaultCryptFilterDictionary();
if (defaultCryptFilterDictionary != null) {
if (defaultCryptFilterDictionary.getLength() != 0) {
setKeyLength(defaultCryptFilterDictionary.getLength());
}
}
{code}
*2. Assumption: Now that it accepts, that the key length is 128, the message
digest is wrong.*
For my test document it now succeeded in creating the cipher, but reported a
wrong padding / a wrong key, when trying doFinal(). I was absolutely certain to
provide the corrrect password, alias and keystore to a matching document,
therefore: The message digest - determining the key - can not be correct. I
found this:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA256().digest(sha1Input);
{code}
And simply changed it to:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA1().digest(sha1Input);
{code}
A change which will most definately brake the AES256 handling, but I ignored
that for now. (possibly V4 and V5 should be handled in separate cases for this
reason?
*Could these assumptions be possibly correct?*
I created a AES128 encrypted document using Adobe DC and wrote a most
simplistic test, that shall load said document using my testkeystore and shall
determine the number of pages:
{code:java}
private static final String password = "w!z%C*F-JaNdRgUk";
private static final String alias = "testnutzer";
@Test
public void openEncDoc() throws Exception {
File keystore = new File("C:\\Users\\cap.SVD\\Desktop", "keystore.pfx");
File encDoc = new File("C:\\Users\\cap.SVD\\Desktop",
"B2-Adobe-128-aes-sec.pdf");
System.out.println("Now loading and decrypting: " +
encDoc.getAbsolutePath());
InputStream keyStoreData = new FileInputStream(keystore);
PDDocument doc = PDDocument.load(encDoc, password, keyStoreData, alias);
try {
System.out.println(" SUCCESS decrypting document, it has " +
doc.getNumberOfPages() + " pages.");
} finally {
keyStoreData.close();
doc.close();
}
}
{code}
Which failed previously for said document and now results in the output:
Now loading and decrypting: C:\Users\cap.SVD\Desktop\B2-Adobe-128-aes-sec.pdf
SUCCESS decrypting document, it has 3 pages.
-The document has been successfully decrypted and the number of pages could be
determined?
I really don't trust myself here, therefore:
- Where am I seeing things too simple or could this possibly be the solution?
I will definately follow this lead for now - as it resulted in a success - but
I don't trust that success yet neither, further testing is required and this is
for now quick and dirty trash code, to simply make it work (somehow).
*Edit:*
Applying the same assumptions to "prepareDocumentForEncryption" also resulted
in a AES128 encrypted document, that could be opened by Adobe DC and still
contained everything it shall contain (or so it seems).
{code:java}
if (version == 4)
{
dictionary.setSubFilter(SUBFILTER5);
mdResult = MessageDigests.getSHA1().digest(shaInput);
COSName aesVName = COSName.AESV2;
prepareEncryptionDictAES(dictionary, aesVName, recipientsFields);
} else if(version == 5) {
dictionary.setSubFilter(SUBFILTER5);
mdResult =
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197520#comment-17197520
]
Christian Appl edited comment on PDFBOX-4421 at 9/17/20, 9:54 AM:
--
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
won't brake for some cases, but your thoughts about it would be absolutely
helpful!)
*Basic Assumption:*
This should work! I can find the parts of the Reference manual, that are
represented here and I can't find big definition gaps at first glance.
*1. Assumption: The assumed key length is wrong (40 instead of 128):*
The method "prepareForDecryption" in PublicKeySecurityHandler is currently
determining the key length via the PDEncryption dictionary
encryption.getLength(). for the case +if (encryption.getVersion() == 4 ||
encryption.getVersion() == 5)+ possibly it should be modified like:
{code:java}
// detect whether AES encryption is used. This assumes that the encryption algo
is
// stored in the PDCryptFilterDictionary
// However, crypt filters are used only when V is 4 or 5.
PDCryptFilterDictionary defaultCryptFilterDictionary =
encryption.getDefaultCryptFilterDictionary();
if (defaultCryptFilterDictionary != null) {
if (defaultCryptFilterDictionary.getLength() != 0) {
setKeyLength(defaultCryptFilterDictionary.getLength());
}
}
{code}
*2. Assumption: Now that it accepts, that the key length is 128, the message
digest is wrong.*
For my test document it now succeeded in creating the cipher, but reported a
wrong padding / a wrong key, when trying doFinal(). I was absolutely certain to
provide the corrrect password, alias and keystore to a matching document,
therefore: The message digest - determining the key - can not be correct. I
found this:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA256().digest(sha1Input);
{code}
And simply changed it to:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA1().digest(sha1Input);
{code}
A change which will most definately brake the AES256 handling, but I ignored
that for now. (possibly V4 and V5 should be handled in separate cases for this
reason?
*Could these assumptions be possibly correct?*
I created a AES128 encrypted document using Adobe DC and wrote a most
simplistic test, that shall load said document using my testkeystore and shall
determine the number of pages:
{code:java}
private static final String password = "w!z%C*F-JaNdRgUk";
private static final String alias = "testnutzer";
@Test
public void openEncDoc() throws Exception {
File keystore = new File("C:\\Users\\cap.SVD\\Desktop", "keystore.pfx");
File encDoc = new File("C:\\Users\\cap.SVD\\Desktop",
"B2-Adobe-128-aes-sec.pdf");
System.out.println("Now loading and decrypting: " +
encDoc.getAbsolutePath());
InputStream keyStoreData = new FileInputStream(keystore);
PDDocument doc = PDDocument.load(encDoc, password, keyStoreData, alias);
try {
System.out.println(" SUCCESS decrypting document, it has " +
doc.getNumberOfPages() + " pages.");
} finally {
keyStoreData.close();
doc.close();
}
}
{code}
Which failed previously for said document and now results in the output:
Now loading and decrypting: C:\Users\cap.SVD\Desktop\B2-Adobe-128-aes-sec.pdf
SUCCESS decrypting document, it has 3 pages.
-The document has been successfully decrypted and the number of pages could be
determined?
I really don't trust myself here, therefore:
- Where am I seeing things too simple or could this possibly be the solution?
I will definately follow this lead for now - as it resulted in a success - but
I don't trust that success yet neither, further testing is required and this is
for now quick and dirty trash code, to simply make it work (somehow).
*Edit:*
Applying the same assumptions to "prepareDocumentForEncryption" also resulted
in a AES128 encrypted document, that could be opened by Adobe DC and still
contained everything it shall contain (or so it seems).
{code:java}
if (version == 4)
{
dictionary.setSubFilter(SUBFILTER5);
mdResult = MessageDigests.getSHA1().digest(shaInput);
COSName aesVName = COSName.AESV2;
prepareEncryptionDictAES(dictionary, aesVName, recipientsFields);
} else if(version == 5) {
dictionary.setSubFilter(SUBFILTER5);
mdResult =
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197520#comment-17197520
]
Christian Appl edited comment on PDFBOX-4421 at 9/17/20, 8:56 AM:
--
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
won't brake for some cases, but your thoughts about it would be absolutely
helpful!)
*Basic Assumption:*
This should work! I can find the parts of the Reference manual, that are
represented here and I can't find big definition gaps at first glance.
*1. Assumption: The assumed key length is wrong (40 instead of 128):*
The method "prepareForDecryption" in PublicKeySecurityHandler is currently
determining the key length via the PDEncryption dictionary
encryption.getLength(). for the case +if (encryption.getVersion() == 4 ||
encryption.getVersion() == 5)+ possibly it should be modified like:
{code:java}
// detect whether AES encryption is used. This assumes that the encryption algo
is
// stored in the PDCryptFilterDictionary
// However, crypt filters are used only when V is 4 or 5.
PDCryptFilterDictionary defaultCryptFilterDictionary =
encryption.getDefaultCryptFilterDictionary();
if (defaultCryptFilterDictionary != null) {
if (defaultCryptFilterDictionary.getLength() != 0) {
setKeyLength(defaultCryptFilterDictionary.getLength());
}
}
{code}
*2. Assumption: Now that it accepts, that the key length is 128, the message
digest is wrong.*
For my test document it now succeeded in creating the cipher, but reported a
wrong padding / a wrong key, when trying doFinal(). I was absolutely certain to
provide the corrrect password, alias and keystore to a matching document,
therefore: The message digest - determining the key - can not be correct. I
found this:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA256().digest(sha1Input);
{code}
And simply changed it to:
{code:java}
if (encryption.getVersion() == 4 || encryption.getVersion() == 5) {
mdResult = MessageDigests.getSHA1().digest(sha1Input);
{code}
A change which will most definately brake the AES256 handling, but I ignored
that for now. (possibly V4 and V5 should be handled in separate cases for this
reason?
*Could these assumptions be possibly correct?*
I created a AES128 encrypted document using Adobe DC and wrote a most
simplistic test, that shall load said document using my testkeystore and shall
determine the number of pages:
{code:java}
private static final String password = "w!z%C*F-JaNdRgUk";
private static final String alias = "testnutzer";
@Test
public void openEncDoc() throws Exception {
File keystore = new File("C:\\Users\\cap.SVD\\Desktop", "keystore.pfx");
File encDoc = new File("C:\\Users\\cap.SVD\\Desktop",
"B2-Adobe-128-aes-sec.pdf");
System.out.println("Now loading and decrypting: " +
encDoc.getAbsolutePath());
InputStream keyStoreData = new FileInputStream(keystore);
PDDocument doc = PDDocument.load(encDoc, password, keyStoreData, alias);
try {
System.out.println(" SUCCESS decrypting document, it has " +
doc.getNumberOfPages() + " pages.");
} finally {
keyStoreData.close();
doc.close();
}
}
{code}
Which failed previously for said document and now results in the output:
_Now loading and decrypting: C:\Users\cap.SVD\Desktop\B2-Adobe-128-aes-sec.pdf
SUCCESS decrypting document, it has 3 pages._
-The document has been successfully decrypted and the number of pages could be
determined?
I really don't trust myself here, therefore:
- Where am I seeing things too simple or could this possibly be the solution?
I will definately follow this lead for now - as it resulted in a success - but
I don't trust that success yet neither, further testing is required and this is
for now quick and dirty trash code, to simply make it work (somehow).
was (Author: capsvd):
Hmmm, I am not entirely sure yet, but possibly the current code is missing only
2 simple steps for success? (speaking about decryption)
I must state this first: I am absolutely uncertain about the following!
I tried to understand and play arround with your code and attempted to
understand which part does what and which variable represents what COS
Structure. Leading me to two simple assumptions, that I guessed would lead to
satisfying results.
(I can neither guarantee, that this really solves the issue, nor that this
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197129#comment-17197129 ] Tilman Hausherr edited comment on PDFBOX-4421 at 9/17/20, 3:44 AM: --- Encryption and decryption is there but IIRC length 128 doesn't work with external software. [Code|https://kb.itextpdf.com/home/it7kb/examples/certificate-encryption] that I used to create an encrypted PDF to try decryption (at that time, I used itext 7.1.3 + bc 1.60). I don't have enough time right now, sadly. Maybe in a few days. Yes this is something you could try. I tried at that time and wasn't successful. The file I created at that time does have /V 4. But it's really the decryption that matters most. There is no real need to encrypt with 128, one should choose 256 (which works). was (Author: tilman): Encryption and decryption is there but IIRC length 128 doesn't work with external software. [Code|https://kb.itextpdf.com/home/it7kb/examples/certificate-encryption] that I used to create an encrypted PDF to try decryption. I don't have enough time right now, sadly. Maybe in a few days. Yes this is something you could try. I tried at that time and wasn't successful. The file I created at that time does have /V 4. But it's really the decryption that matters most. There is no real need to encrypt with 128, one should choose 256 (which works). > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Priority: Major > Labels: AES128 > Attachments: image-2020-09-16-10-32-11-060.png, > image-2020-09-16-10-33-55-201.png, image-2020-09-16-11-55-33-275.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196790#comment-17196790
]
Christian Appl edited comment on PDFBOX-4421 at 9/16/20, 2:37 PM:
--
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue? I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the entries "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that
PublicKeySecurityHandler should be operating somewhat comparable to the
StandardSecurityHandler, concerning algorithms and especially "V" (which
already seems to define behaviour for V 0 through 6).
I think exactly here would be the place to start this: (?)
!image-2020-09-16-11-55-33-275.png!
was (Author: capsvd):
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue? I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that
PublicKeySecurityHandler should be operating somewhat comparable to the
StandardSecurityHandler, concerning algorithms and especially "V" (which
already seems to define behaviour for V 0 through 6).
I think exactly here would be the place to start this: (?)
!image-2020-09-16-11-55-33-275.png!
> Add support for AES128 encryption for public key
>
>
> Key: PDFBOX-4421
> URL: https://issues.apache.org/jira/browse/PDFBOX-4421
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: AES128
> Attachments: image-2020-09-16-10-32-11-060.png,
> image-2020-09-16-10-33-55-201.png, image-2020-09-16-11-55-33-275.png
>
>
> Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128
> doesn't when the file is generated by an external software. (local tests
> work) We should at least get the decryption to work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196790#comment-17196790
]
Christian Appl edited comment on PDFBOX-4421 at 9/16/20, 9:56 AM:
--
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue? I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that
PublicKeySecurityHandler should be operating somewhat comparable to the
StandardSecurityHandler, concerning algorithms and especially "V" (which
already seems to define behaviour for V 0 through 6).
I think exactly here would be the place to start this: (?)
!image-2020-09-16-11-55-33-275.png!
was (Author: capsvd):
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue? I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that
PublicKeySecurityHandler should be operating somewhat comparable to the
StandardSecurityHandler, concerning algorithms and especially "V" (which
already seems to define behaviour for V 0 through 6.
I think exactly here would be the place to start this: (?)
!image-2020-09-16-11-55-33-275.png!
> Add support for AES128 encryption for public key
>
>
> Key: PDFBOX-4421
> URL: https://issues.apache.org/jira/browse/PDFBOX-4421
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: AES128
> Attachments: image-2020-09-16-10-32-11-060.png,
> image-2020-09-16-10-33-55-201.png, image-2020-09-16-11-55-33-275.png
>
>
> Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128
> doesn't when the file is generated by an external software. (local tests
> work) We should at least get the decryption to work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196790#comment-17196790
]
Christian Appl edited comment on PDFBOX-4421 at 9/16/20, 9:55 AM:
--
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue? I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that
PublicKeySecurityHandler should be operating somewhat comparable to the
StandardSecurityHandler, concerning algorithms and especially "V" (which
already seems to define behaviour for V 0 through 6.
I think exactly here would be the place to start this: (?)
!image-2020-09-16-11-55-33-275.png!
was (Author: capsvd):
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue. I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
> Add support for AES128 encryption for public key
>
>
> Key: PDFBOX-4421
> URL: https://issues.apache.org/jira/browse/PDFBOX-4421
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: AES128
> Attachments: image-2020-09-16-10-32-11-060.png,
> image-2020-09-16-10-33-55-201.png, image-2020-09-16-11-55-33-275.png
>
>
> Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128
> doesn't when the file is generated by an external software. (local tests
> work) We should at least get the decryption to work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196790#comment-17196790
]
Christian Appl edited comment on PDFBOX-4421 at 9/16/20, 8:56 AM:
--
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue. I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will
create a key of insufficient length and padding (length: 10 = 40/8+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
was (Author: capsvd):
It would be one of our requirements for this to work and maybe we could
contribute to resolve this issue. I am currently evaluating what might be the
exact problem here and how it could be resolved.
*As far as I understand it:*
{color:#00}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color}
attempts to determine a key of the correct length and content using the method
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a
document's "Encryption" dictionary, which should work, if the dictionary value
"V" is set to either 2 or 3.
But as "Length" is optional, defaults to 40 and is not used by "V" 4 this will
create a key of insufficient length and padding (length 10 = (40/8)+5) for
AES128 encrypted documents (As e.g. currently created by Adobe DC)
!image-2020-09-16-10-32-11-060.png!
According to the Reference Manual "V" 4 should make use of the streams "CF"
"StmF" "StrF" to provide information about the used algorithm:
!image-2020-09-16-10-33-55-201.png!
*Questions:*
- Is my analysis correct?
- Is implementing "V" 4 the missing piece here?
- Do you have further information, that could be helpful to implement this?
- Is this something, that I could possibly help with, or is a solution coming
anyway?
> Add support for AES128 encryption for public key
>
>
> Key: PDFBOX-4421
> URL: https://issues.apache.org/jira/browse/PDFBOX-4421
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto
>Affects Versions: 2.0.13
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: AES128
> Attachments: image-2020-09-16-10-32-11-060.png,
> image-2020-09-16-10-33-55-201.png
>
>
> Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128
> doesn't when the file is generated by an external software. (local tests
> work) We should at least get the decryption to work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
