[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #13696 [Tor]: Use syscall-based entropy reading where possible.
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs