[tor-bugs] #13696 [Tor]: Use syscall-based entropy reading where possible.

[Tor Bug Tracker & Wiki]

#13696: Use syscall-based entropy reading where possible.
-------------------------+--------------------------------
 Reporter:  nickm        |          Owner:  yawning
     Type:  enhancement  |         Status:  needs_revision
 Priority:  Medium       |      Milestone:  Tor: 0.2.???
Component:  Tor          |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  tor-relay    |  Actual Points:
Parent ID:               |         Points:
  Sponsor:               |
-------------------------+--------------------------------

Comment (by teor):

 Replying to [comment:12 yawning]:
 > Replying to [comment:11 teor]:
 > > I can't see the point of calling a system call that wraps /dev/random.
 We'd just be reducing performance, and exposing ourselves to any security
 issues in the wrappers.
 >
 > Disagree, at least for Linux's getrandom(), which does happen to pull
 it's entropy from /dev/urandom, in that behavior is a lot more clear and
 well defined (Eg: The syscall will block if the device isn't sufficiently
 seeded, requests under a certain size will not be interrupted by signals
 or return a short read).
 >
 > OpenBSD's getentropy() is a better getrandom() in that there's less
 complexity and error handling required, though I'm sure the OpenBSD people
 will raise eyebrows at us for not using arc4random().
 >
 > If the OSX call happens to provide similar advantages over reading from
 /dev/urandom or similar, it should be used for those reasons.

 Apple doesn't seem to document the semantics of these system calls in any
 detail, at least in any documentation I can find. But the code is open
 source (well, "open" for the purposes of the kind of review I'm doing
 right now), so I can do some spelunking.

 Our options on OS X / iOS are:
 * /dev/random
   * available on every OS X
   * sandboxed on iOS
     * source: https://www.mikeash.com/pyblog/friday-qa-2011-03-18-random-
 numbers.html#comment-3e4213b49fef1f45568897721e7ad921
     * I wonder what tor / OpenSSL does on iOS at the moment - does it have
 very poor randomness because reading /dev/random fails?
   * never blocks (uses Yarrow, has BSD-like semantics)
 * SecRandomCopyBytes in Security/SecRandom.h
   * available MAC_10_7, IPHONE_2_0
   * documented to read from /dev/random (it does, but only to seed an
 internal CSPRNG)
   * actually calls CCRandomCopyBytes() in SecurityFramework 57031.40.6
 * CCRandomGenerateBytes in CommonCrypto/CommonRandom.h
   * available MAC_10_10, IPHONE_8_0
   * not documented anywhere I could find
   * code reads from /dev/random to get entropy, then produces random
 numbers using NIST SP 800-90 March 2007 using aes_ltc_ecb_encrypt_mode /
 ltc_rijndael_keysched.
     * maximum request size of 2^16 bytes
     * reseeds from /dev/random every 2^30 bytes (NIST says at least 2^48,
 Apple does 2^30)
   * alternately, if passed kCCRandomDevRandom it will read directly from
 /dev/random each time
   * in either case, there are a number of internal retries (for
 interrupted systems calls etc.) and some error checking that makes calling
 these functions worthwhile

 There's no option for iOS 1, but anyone still running iOS 1 isn't likely
 to be able to run tor. (And probably has other security concerns.)

 So I'm happy to write the code - I'll ask for random bytes from Apple's
 implementation of the NIST 2007 CSPRNG, unless anyone thinks that's a bad
 idea. (We might end up using the NIST version via SecRandomCopyBytes, if
 it's the only function available on that platform.)

 Yawning, let me know when you're happy with your branch, and I'll add the
 OS X / iOS code to it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13696#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online