[Webfunds-devel] good keys, bad keys...

Tue, 05 Sep 2000 18:20:18 +0200

Ian Grigg <iang@systemics.com> wrote:

> Oh?  I would have thought that verification was
> safe, it is just reading data, is it not?

No it is not. Verification of a signature involves several method calls 
(init, update and verify). Normally those are on a separate signature 
object, but when I hacked some high-level classes together I decided to 
combine them in the PGPPublicKey class.

> If this *is* indeed the problem,
> a) how do I confirm it, and

Construct a new PGPPublicKey object containing the operator key for every 
thread. If that's already done (as you suggest below), then it may be a 
different problem with no obvious plausible cause.

> b) what degree of difficulty will it incur to
> make it threadsafe?

I'm working on a redesign of the high-level classes where this 
functionality will be split out into a separate signature class. This 
should solve most threading problems. The current classes were just a big 
hack (I even documented that ;-)

> One thing that may currently work in our favour is
> another "bug" ...  in that each thread acquires the
> key independantly, when they should take some measure
> of shared approach.  [Hmm, thinking about that, the
> signing cert may be the same object ... No, it's made
> a-fresh for each access at least as it gets the
> server [operator] cert from the Contract.java, so
> all objects should be the same.]
>
> Are independantly created objects (from distinct
> encoded data) safe from each other?  Any statics or
> other side-effects?

If keyA.equals(keyB) but not keyA == keyB (i.e. two different keys that 
contain the same data, but are physically two different objects in memory) 
then there should be no threading problems.

Edwin