SecRandomCopyBytes versus /dev/random

Hello m.winkler,

Why do you care? iOS and macOS are merging into one. These days, macOS is effectively a port of iOS. Apple does update documentation from time to time. I suggest that you directly use SecRandomCopyBytes if you need that functionality. If you are porting some Linux code that expects to use /dev/random or /dev/urandom, then your ported code will work fine. It is a pointless exercise to try to get any information at this level of detail from Apple. Even if an Apple engineer sees your posts and responds, there is no guarantee that said response will still be valid in six months. If this level of uncertaintly is unacceptable, then you can always use some 3rd partry library to give you the specific details that you are looking for.

I’m inclined to agree with john daniel here. The documentation for

SecRandomCopyBytes

makes it clear that it is a valid source of cryptographically sound random numbers. Either you trust Apple in this regard, or you don’t, and the latter leads to madness.

Having said that, most of this stuff is in the Darwin open source. You can just start with the code for

SecRandomCopyBytes

and pull on the thread from there. I took a quick look at this myself and it seems that in recent releases

SecRandomCopyBytes

has move over from

/dev/random

to using Common Crypto (also in Darwin), which in turn uses Core Crypto (not in Darwin, but available here). And that is the likely explanation for the documentation change you noticed.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

@eskimo, @john_daniel: thanks,

your answers pointed me in the right direction, there is a rather large comment in the header file https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60027/Source/CommonCryptoSPI/CommonRandomSPI.h.

So it looks like SecRandomCopyBytes uses:

https://opensource.apple.com/source/xnu/xnu-4570.41.2/osfmk/corecrypto/ccdbrg/src/ccdrbg_nisthmac.c.auto.html

While /dev/random uses:

https://opensource.apple.com/source/xnu/xnu-4570.41.2/osfmk/prng/random.c.auto.html

SecRandomCopyBytes uses a random number generated that is described in https://csrc.nist.gov/publications/detail/sp/800-90a/archive/2012-01-23

While /dev/random uses a Yarrow implementation.

It would have hoped to find this information in the documentation, without the need to skim sourcecode.

Thanks.

Thanks for posting all that info.

It would have hoped to find this information in the documentation …

Why? We generally don’t document the implementation of our APIs, we document the semantics. The semantics of

SecRandomCopyBytes

is that it provides cryptographically sound random numbers. The exact mechanism by which it does that is subject to change (and has already changed once).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I know this is an old thread but these answers are ridiculous. Telling a developer that they should not care about how *Security* APIs work is awful, and asking "why" it should be adequately documented is obnoxious. Not to mention the absurdity of "Either you trust Apple in this regard, or you don’t, and the latter leads to madness". I have seen a bunch of examples of Apple's horrible crypto api documentation leading to mistakes that completely ruin a programs security (people use kCCModeCBC in a function where it actually equals kCCOptionECBMode !!).

And it matters whether the RNG is the NIST standard or not. There are real world requirements and regulations on software that requires developers use the NIST recomendations. If I was legally required to determine whether my software was compliant and the necessary documentation did not exist I would be a little annoyed. If I then came to the forum and was told "you shouldn't care about this, why do you want it documented?" I would be ******. For most developers doing crypto right is already hard enough, and these replies are worse than useless.

People make mistakes writing software all the time, regardless of how well-documented the APIs might be.

Apple sells devices for the consumer market. If you are developing software for regulated markets, then security and standards compliance are your responsibilities, not Apple's. It's your code. If you need a specific implementation, then you have to implement that. There is a reason why software for regulated markets tends to cost orders of magnitude more than consumer software.

>If you need a specific implementation, then you have to implement that.

Its widely accepted that telling people to implement their own crypto is the worst possible advice. Also consumer banking is regulated and institutions have their own internal security requirements. Its surreal that the statement "Security APIs should have proper documentation" is getting this kind of pushback.

Its widely accepted that telling people to implement their own crypto is the worst possible advice.

It is, in a consumer market. There is zero chance that any app developer off the street is going to be able to implement something better than what Apple has done.

Also consumer banking is regulated and institutions have their own internal security requirements.

Which is why banks don't use consumer software for internal security requirements. Please don't confuse your mobile banking app with something a bank would use for their own systems.

Apple is free to change its underlying implementations at any time. As eskimo said, they've already done that with SecRandomCopyBytes. If there is a requirements document that specifies things to this level of detail, then using a system-provided utility, which is subject to the whims and updates of the vendor, would not be acceptable.