[tahoe-lafs-trac-stream] [tahoe-lafs] #1924: NetBSD < 6.0 /dev/random appears to break RSA keygen in test suites

tahoe-lafs trac at tahoe-lafs.org
Mon Mar 11 08:50:39 UTC 2013


#1924: NetBSD < 6.0 /dev/random appears to break RSA keygen in test suites
-------------------------------+------------------------------------
     Reporter:  midnightmagic  |      Owner:
         Type:  defect         |     Status:  new
     Priority:  major          |  Milestone:  undecided
    Component:  code           |    Version:  1.9.2
   Resolution:                 |   Keywords:  netbsd random cryptopp
Launchpad Bug:                 |
-------------------------------+------------------------------------

Comment (by midnightmagic):

 I will test your debug routines. I am fairly confident that the only time
 this race might occur would be if there were another thread that were
 doing it incorrectly after the fact.

 I wrote this in #tahoe-lafs a moment ago and realised I should put it in
 here instead:

  There is a match between this error and the pycrypto++ self-test program
 that coincidentally happens (and doesn't happen)  at exactly the same
 frequency as whether I have a high-supply /dev/random (netbsd6 kernel) or
 not (netbsd5 kernel).

  Specifically, in the cryptest.exe program validation routines, it will
 *block* when reading from /dev/random, also the kernel itself sits there
 picking its nose "waiting" for "entropy".

  Finally, it will emit an error.. but it won't actually exit. it just
 complains about the lack of bytes from /dev/random and then at the end of
 the validation it will insist the system failed some of the tests.

  In wrapping crypto++, does pycryptopp disable any blocking reads from
 /dev/random in some fashion?

  Here's the error under similar conditions to where the pycryptopp stuff
 is failing:
 {{{
 ./cryptest.exe v
 [...]
   Testing operating system provided blocking random number generator...
   FAILED:  it took 361 seconds to generate 1 bytes
 [...]
 }}}

 I have now switched the buildmachine back to the NetBSD 5.x kernel which
 can be emptied of its entropy fairly easily, so don't kill the buildbots
 if they start choking. :-)

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1924#comment:8>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list