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

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Sep 21, 2003 at 04:53:47PM +0200, Mikael Hakman wrote:
> 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.

The behavior of the JCE Cipher class is rather poorly specified, so the
only guide is to try to copy Sun's behavior.

> I think update() have to be smarter. Please see my answer to Raif concerning
> this too, especially CipherStreams.
> 

I do agree -- CipherAdapter should be better than it is now. The
existing implementation was meant to reproduce -- at least -- the basic
function of GNU Crypto's API, which processes input data one block at a
time. As such it really only expects certain kinds of input, and I'm not
surprised that it breaks down at limit cases.

> > > 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?
> 

I use `gpg --clearsign'. 

You can use whatever you like, however. There isn't any rule for
digitally-signed messages on this list.

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/bcu2gAuWMgRGsWsRApJkAJ9ZdNf5uhRTrswvpIxoFu/a7cFlRwCfZDWd
Aa/f8OBCBl6WqdrtCzeyOV8=
=Jltj
-----END PGP SIGNATURE-----