Re: javax.crypto fixes

[Marco Trudel <mtrudel at gmx dot ch>]

Andrew Haley wrote:
> Marco Trudel writes:
>  > I fixed some stuff in javax.crypto:
>  > 
>  > 1. decryption with padding was broken/wrong handled
>  > 2. CipherOutputStream was completly broken/unusuable
>  > 3. PKCS7 did an unnecessary test
>  > 
>  > Cipher, CipherOutputStream and CipherInputStream now work as expected.
>  > 
>  > 
>  > 1. decryption with padding needs to keep back the last block for final 
>  > unpadding when doFinal() is called. This wasn't done. doFinal() lead to 
>  > an exception.
>  > Actually, padded decrypting only worked correct when all data was passed 
>  > by doFinal(byte[]) or when there where update() calls that filled the 
>  > data to a multiple of the blocklengh and doFinal was called with the 
>  > rest of the data.
>  > This fixes CiperInputStream as well, because it relies on the correct 
>  > doFinal() handling of the cipher class.
>  > 
>  > 2. CipherOutputstream had a lot of code that did nothing except leading 
>  > to a NullPointerException when calling write(...) (outBuffer was never 
>  > initialized). It looks to me like the code should have worked around the 
>  > bugs in CipherAdapter. But that should have been done in CipherInputStream?!
>  > 
>  > 3. PKCS7 unpadding tested a value that was just read with itself. Fixed 
>  > it because I was already reading it... Nothing big...
>  > 
>  > 
>  > Any comments? Hints?
>  > 
>  > I have no committing rights and the copyright assignment papers are not 
>  > yet arrived with mail. This might be a problem...
>  > 
>  > Ah, and finally: this is actually classpath code, can someone check that 
>  > in there too, as soon as it's ok for gcj?
>
> You better post this to classpath-patches.

Done. I will see that it finds its way into GCJ as well, as soon as it 
has been committed into classpath...

Marco