[OTR-dev] solution for slow key generation

[Thorsten Glaser]

Hi!

Jonathan complained that OTR key generation took about an hour on his NetBSD
computer (he’ll probably provide specs if desired). I dug into the code and
found out that this is because libgcrypt (sucky code…) uses /dev/srandom¹ for
key generation entropy, which uses blocking reads.

While it didn’t take that long for me on MirOS – less than one minute – I’ve
written a tool intended to be used as a contributed script, not to replace
the code inside of libotr. This script² uses openssl for key generation, so
Debian users should take care ☺ as not even using -rand helps with the bug
they had. Other dependencies are mksh³, chmod, cat, and of course the openssl
command-line tool. Add some suitable entropy source (can optionally be given
as command line argument) or pull 32 (additional) bytes from me⁴ (this is a
slow box on a slow ADSL connection, but it has good entropy quality⁵).

Like I said, I don’t want to replace or criticise anything (maybe except the
decision to not use libcrypto/libssl in the first place ☺), but I’d be glad
if you people would look over that script and maybe include it as “contrib”
in the next libotr distribution.

① may be named different on your OS – http://www.mirbsd.org/man/srandom.4
② http://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/otr-genkey.sh
③ http://mirbsd.de/mksh – part of many distributions, ports trees, etc.
④ https://herc.mirbsd.org/rb.cgi?from_otr-dev_ml
⑤ https://www.cacert.at/cgi-bin/rngresults – scroll down to the bottom

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs