Prefer arc4random on Apple platforms

[res0nance]

On Apple platforms arc4random is always available and it never fails. This removes a possible failure mode of liboqs on Apple platforms with getentropy().

The man page for getentropy() on MacOSX also discourages its use

However, it should be noted that getentropy() is primarily intended for use in the construction and seeding of userspace PRNGs like
     arc4random(3) or CC_crypto(3).  Clients who simply require random data should use arc4random(3), CCRandomGenerateBytes() from
     CC_crypto(3), or SecRandomCopyBytes() from the Security framework instead of getentropy() or random(4)

On iOS we currently use SecRandomCopyBytes() this requires linking to the Security framework and the call can fail. We have run into issues with this call failing so we propose using arc4random_buf() as it can never fail.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in oqs-provider, OQS-OpenSSL, OQS-BoringSSL, and OQS-OpenSSH will also need to be ready for review and merge by the time this is merged.)

[dstebila]

We don't have an iOS test platform; have you been able to test it there to confirm it builds?

[res0nance]

We don't have an iOS test platform; have you been able to test it there to confirm it builds?

I have tested it on tvOS, iOS, macOS m1. They all compile fine.

Maybe we can use the file in https://github.com/leetal/ios-cmake to setup builds for the iOS / tvOS platforms? I'm assuming the licensing is fine. I can set that up in a different PR.

[baentsch]

Thanks for the suggestion(s) and this PR to improve building on those platforms!

One concern, though

so we propose using arc4random_buf() as it can never fail.

Can you please link to documentation confirming that arc4random_buf is at least as secure as SecRandomCopyBytes? Something with "RC4" in its name doesn't create warm and fuzzy feelings about its security properties :-)

Otherwise the PR LGTM, particularly if you confirm

tested it on tvOS, iOS, macOS m1. They all compile fine.

[res0nance]

Thanks for the suggestion(s) and this PR to improve building on those platforms!

One concern, though

so we propose using arc4random_buf() as it can never fail.

Can you please link to documentation confirming that arc4random_buf is at least as secure as SecRandomCopyBytes? Something with "RC4" in its name doesn't create warm and fuzzy feelings about its security properties :-)

Otherwise the PR LGTM, particularly if you confirm

tested it on tvOS, iOS, macOS m1. They all compile fine.

Ah the "RC4" name is from the old days, from the manpage

The original version of this random number generator used the RC4
    (also known as ARC4) algorithm. In OS X 10.12 it was replaced with the
    NIST-approved AES cipher, and it may be replaced again in the future as
    cryptographic techniques advance

On the topic of being secure, from the manpage

These functions use a cryptographic pseudo-random number generator
    to generate high quality random bytes very quickly. One data pool is used
    for all consumers in a process, so that consumption under program flow can
    act as additional stirring. The subsystem is re-seeded from the kernel
    random number subsystem on a regular basis

It seems like the intent of apple here is to provide a simple to use cryptographically-secure random number generator that they will update as technology progresses.

[dstebila]

so we propose using arc4random_buf() as it can never fail.

Can you please link to documentation confirming that arc4random_buf is at least as secure as SecRandomCopyBytes? Something with "RC4" in its name doesn't create warm and fuzzy feelings about its security properties :-)

I was worried about that too, but also found the passage that res0nance quoted saying that it's no longer specifically using RC4. So I think it's okay.

[baentsch]

Maybe we can use the file in https://github.com/leetal/ios-cmake to setup builds for the iOS / tvOS platforms? I'm assuming the licensing is fine. I can set that up in a different PR.

Sounds like a nice addition to avoid regression, too. Looking forward to the PR. Any chance to run the result in CI, too (in an emulator)?