How many bits of entropy can I expect from /dev/urandom in iOS? Apple's latest security documentation indicates that it now uses CTR_DRBG for generating pseudo-random numbers (previously Yarrow instead of CTR_DRBG), using "timing variations during boot" and "interrupt timing once the device has booted" as seeds. Calls to the iOS API SecRandomCopyBytes will retrieve random bytes from /dev/random by default. Apple's random(4) man page seems to suggest that their /dev/random is non-blocking, but that it somehow does not need to block in order to ensure fresh entropic bytes:


  /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom
  will produce lower quality output if the entropy pool drains, while
  /dev/random will prefer to block and wait for additional entropy to be
  collected.  With Yarrow, this choice and distinction is not necessary,
  and the two devices behave identically. You may use either.


NIST's DRBG validation list indicates that Apple is using AES-128 in counter mode as a pseudo-random function for CTR_DRBG.

So, how many bits of entropy can we expect out of SecRandomCopyBytes? If I query it for 256 bits of entropy, will I instead get 128 bits of reasonably entropic data, potentially followed by another 128 bits of less entropy data due to the lack of blocking in iOS's /dev/random?
I mailed Craig Federighi recently about this, concerned that macOS wasn’t capable of generating >128bit quality keys. 

He responded!


  “The source you were referencing is out of date.  You can find more current informations here:   FIPS certification document, section 7: "The NDRNG feeds entropy from the pool into the DRBG on demand.  The NDRNG provides 256-bits of entropy.””