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

[tahoe-lafs]

#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 zooko):

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

 Oooh.

 {{{
     AutoSeededRandomPool osrng(false);
 }}}

 from:

 [//trac/pycryptopp/browser/git/src/pycryptopp/publickey/rsamodule.cpp?annotate=blame&rev=9c884d4ea2c75bc47dc49d4c404bfc5a9fc3b437#L297]

 The {{{false}}} is the argument to the parameter "blocking":
 [//trac/pycryptopp/browser/git/src-
 cryptopp/osrng.h?annotate=blame&rev=9c884d4ea2c75bc47dc49d4c404bfc5a9fc3b437#L84].

 However, I still refuse to believe that if I tell it to use an RNG in non-
 blocking mode, and the OS is providing an underlying RNG which is
 blocking, that this means it generates a {{{yᵉ ≠ x mod N}}}. What it
 //should// do if I require non-blocking and the underlying pool is
 blocking is either use a non-blocking underlying pool (/dev/urandom), or
 raise an exception.

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