Tilman Hausherr commented on PDFBOX-3889:

Maybe this is a misunderstanding - the file is fully decrypted after 
loadNonSeq() returns. I.e. unlike with load() you don't have to call 
openProtection() to decrypt.

If I'm wrong then please post the smallest possible code that reproduces the 

> javax.crypto.BadPaddingException: Given final block not properly padded
> -----------------------------------------------------------------------
>                 Key: PDFBOX-3889
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-3889
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Crypto
>    Affects Versions: 1.8.13
>         Environment: Java 1.8.  Pdfbox 1.8.13  Windows and Linux
>            Reporter: Lucille Wilson
>              Labels: security
>         Attachments: 14-03-1159.pdf
>   Original Estimate: 24h
>  Remaining Estimate: 24h
> Using the attached pdf, When running the pdf through 
> org.apache.pdfbox.pdmodel.encryption.SecurityHandler I get 
> BadPaddingException.
> The exception occurs when it is processing 
> nextObj = COSObject{3304,0} I see: nextCOSBase = 
> COSDictionary{(COSName{Length}:COSInt{3504}) (COSName{Subtype}:COSName{XML}) 
> (COSName{Type}:COSName{Metadata}) } 
> The problem is that SecurityHandler.proceedDecryption() runs  
> decryptObject(nextObj);
>  and then decrypt(base, objNum, genNum) and then decryptStream()
> However for this object decryptStream doesn't actually decrypt anything 
> because the type is xml.  
> So when decryptStream calls encryptData() encryptData() throws the bad packet 
> exception.
>  output.write(decryptCipher.doFinal()); throws the exception because the data 
> buffer is all zeros.  It has nothing in it.  I recommend that encryption be 
> skipped if the data buffer has all zeros.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Reply via email to