[OTR-users] Pidgin freezes on OTR private key generation

[Michael McConville]

Tomasz Wasilczyk wrote:
> Michael McConville wrote:
> > Lachezar Dobrev wrote:
> >> You may not have enough entropy! Try downloading something big, or
> >> watch a film off your hard drive. Move your mouse, type on the
> >> keyboard.
> >>
> >> That said… I do think this operation should be asynchronous, and not
> >> hang the UI.
> >
> > True. I think Tomasz may actually already have a patch in his branch
> > for this.
> >
> > That said, the other option is to change the gcrypt randomness
> > quality level (of type gcry_random_level_t) from
> > GCRY_VERY_STRONG_RANDOM to GCRY_STRONG_RANDOM. These represent
> > /dev/random and /dev/urandom respectively.
> >
> > I think the only concern is that Linux doesn't block /dev/urandom
> > until it has sufficient entropy. However, (IIUC) this is mostly only
> > a problem in early boot stages and on embedded devices, which don't
> > apply to most OTR use cases. OTR already uses /dev/urandom for
> > ephemeral keys.
> > 
> I don't think decreasing security level (even hyphotetical) is any
> option to just making that asynchronous. Especially when a patch is
> here.

"Quality" is a dubious term here, though. I'd have to look at the gcrypt
code again, but I recall them just being aliases of /dev/random and
/dev/urandom. Crypto code increasingly assumes /dev/urandom to be secure
(and it almost always is), so it's a reasonable option.

I've seen Pidgin hang on recent releases of Debian/Ubuntu for 5+ minutes
when generating OTR identity keys. As this email thread exemplifies,
this hanging can concern or even spook users. There's also the question
of what exactly the UI does if OTR takes five minutes to generate an
identity key. OTR chat has to be disabled for that account. How do we
signal this to the user? What if they get impatient or think OTR is
broken?