Re: [GNU Crypto] What to do with bugs?

[Mikael Hakman]

On Sunday, 21 September, 2003 06.47,Casey Marshall wrote:
> On Sat, Sep 20, 2003 at 10:01:46PM +0200, Mikael Hakman wrote:
>
> > 2. gnu.crypto.jce.cipher.CipherAdapter
> >
> > engineDoFinal(byte[] input, int off, int len)
> >
> > Errors when decrypting when len<(len of actual padding) - some or all
pad
> > bytes has already been processed in such case, in particular when
parameter
> > len=0. This happens when application calls e.g. doFinal() after is has
> > processed the whole input.
> >
>
> This isn't a bug. If you update the entire input with one of the
> update() methods, the decrypted padding will be returned by that method.
> If you then call doFinal the padding is already gone.
>
> You shouldn't use the no-argument doFinal() if you are decrypting with a
> padded block cipher.
>
> Sun's Cipher API is retarded. Use something else if you can.



I'm not prepared to compare JCE spec with other possible APIs. I'm simply
trying to use what I think most people (will) use for the purpose when doing
crypto in Java. When I choose a particular API then I stick to it and expect
its
implementations to comply 100%. Right now I'm in the process of selecting
an JCE implementation and I don't mind to help making the selected one
better and compliant with the spec.



I'm not sure that JCE forbids you to call empty doFinal() when using
padding.
I think update() have to be smarter. Please see my answer to Raif concerning
this too, especially CipherStreams.

> > 5. What are gpg commands to get the envelope you are providing? Is there
> > any plugin for OE that can automatically pack-in/pack-out emails?
> >
>
> If you mean how to verify PGP-signed data, something like
>
> gpg --verify <signed-message>



The opposite - how to generate the envelope like one that you are providing
so that you can easily verify my messages. There are a number of options for
gpg - which ones are customary to use when sending mail to this list?



Mikael