[OTR-dev] Re: Requirements for libotr4

[Uli M]

Ian,

one last question: Is the assessment I made somewhere else in this thread[1]
correct that not creating a key in the create privkey callback leads to the same
result as not defining the callback at all? I.e. is it indeed OK to start
background generation there and just let the ongoing handshake fail?

Uli

[1] http://article.gmane.org/gmane.comp.security.otr.devel/892

On Wed 09.07.08 11:11, Ian Goldberg wrote:
> On Wed, Jul 09, 2008 at 11:56:01AM +0200, Uli M wrote:
> > On Sun 06.07.08 18:09, Ian Goldberg wrote:
> > > On Sat, Jun 21, 2008 at 10:52:05AM -0400, Ian Goldberg wrote:
> > > > With the specified division of threads, the callbacks are now
> > > > unnecessary.
> > > 
> > > I've checked in the support for background privkey generation.  Here are the
> > > new functions in privkey.h.
> > > 
> > > Uli, does this do what you want?
> > 
> > Yeah, that looks good. There's just one problem I see: there's no
> > cancel method. So when the background generation fails or is aborted
> > and then at a later point in time generate_start is called again for
> > the same accountname/protocol pair I guess it will return
> > GPG_ERR_EEXIST (because generate_finish hasn't been called for this
> > pair).
> > 
> > One could work around this in the app by storing the newkey pointers
> > of aborted generations for later reuse in generate_calculate calls but
> > a cancel method would be better.
> 
> Fair enough.  I just checked this in:
> 
> /* Call this from the main thread only, in the event that the background
>  * thread generating the key is cancelled.  The newkey is deallocated,
>  * and must not be used further. */
> void otrl_privkey_generate_cancel(OtrlUserState us, void *newkey);
> 
>    - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev