-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switches Darwin to arc4random #6350
Switches Darwin to arc4random #6350
Conversation
@@ -7,6 +7,8 @@ lib LibC | |||
rem : Int | |||
end | |||
|
|||
fun arc4random : UInt32 | |||
fun arc4random_buf(x0 : Void*, x1 : SizeT) : Void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please:
- Replace
Void*
withUInt8*
- Remove
: Void
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be the case even if it goes against the existing c definition?
void
arc4random_buf(void *buf, size_t nbytes);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that works... I thought Void*
didn't work in Crystal, but for some reason it does...
It seems there's also a Void
top-level type... it seems it was never removed from the language...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The : Void
is implicit and the void *
should be UInt8*
in crystal. @asterite is correct.
From the libsodium developers:
It seems arc4random on osx is actually a userspace PRNG, which is not what we want here. |
@RX14 - Based on my current research.
Its great that libsodium thinks they can do better. OpenBSD I am sure goes even further then libsodium. But I am not proposing we shim in (if even possible) OpenBSD's implementation or link in yet another library. Crystal should use the fastest/best built-in CSPRNG. On Darwin based systems that is |
I'd trust the libsodium guys far far more than you or I. If they say it's wrong, it's wrong. And risking this just for performance? |
@RX14 - You can trust whoever you like. I don't trust the libsodium guys and I would certainly trust the Apple guys before them with regards to how something is implemented in macOS. I happen to be of the perspective everyone should just duplicate OpenBSD's All the official documentation says use In case I need to say it again. Apple explicitly says:
and,
|
And until recently the linux manpages said using urandom wasn't cryptographically safe, which was against the advice of every cryptographer out there. At the end of the day, this is a performance problem, and if there's any conflict at all, i'd rather stick with what we know works and is secure. |
So, there are two main problems with arc4random
so even if we ignore first point, arc4random shouldn't be used on OSX10.11 and older. On the other hand, On the other other hand, it a libsodium issue cited before tells that
so it in theory can fallback to reading from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Random::Secure
MUST be a CSPRNG (cryptographically secure pseudo random number generator) and the underlying OS syscalls/sources we use must be proven secure by cryptographers and outlandish libraries written by them (e.g. libsodium).
I believe it was demonstrated that arc4random
is either bad or imperfect as a trustable CSPRNG in older FreeBSD and macOS releases (at least). Maybe that changed in recent releases, but we need proof of that. Please conduct researches to debunk libsodium statements, they'll love it ❤️
If proven, we must use arc4random
on safe systems only, preferably with a runtime check —e.g. we use the getrandom
syscall on linux then fallback to /dev/urandom
, binaries are safe to run on any kernel.
Until then, let's hold on.
And even if arc4random is secure on 10.12, are all the runtime checks and complexity (read: vulnerabilities) worth it? Just for some performance? |
Closing. We can't trust ourselves on security topics. We need strong guarantees from cryptographers that something is safe and correct. Sadly, we don't have enough guarantees that |
Based on discussions on #6340.
Note: The same could also be done for FreeBSD.