-
Notifications
You must be signed in to change notification settings - Fork 7.9k
PHP 5.6 mcrypt_create_iv() improvement #579
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
Conversation
yohgaki
commented
Feb 3, 2014
- Add /dev/arandom support
- Raise error for dangerous usage
+1000. I really hope this gets merged. |
random_source = "/dev/random"; | ||
break; | ||
default: | ||
random_source = "/dev/random"; |
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.
Why use a default setting that may exhaust the entropy source? I would opt for either RAND or URANDOM as the fallback, the former giving two notices :)
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 know it may exhaust. The only reason why I coded like this is "it was the default".
IV should be unpredictable, but it's not a secret. I would rather make /dev/urandom a default. (Windows uses their own API) Since this is for PHP 5.6, it would better to be changed now.
As IVs are not secrets, you should never need to generate them with such high quality random numbers. They don't have forward secrecy requirements (quite the opposite, they are assumed public). So unless you're using the function to create key material, there is no need for arandom. And if you are, perhaps it is time to build a dedicated generator for that... |
@ircmaxell Yes, you do need to use high quality random numbers. IV's don't have to be kept secret after they are used, but they need to be unpredictable. If the attacker can predict the IV before providing a chosen plaintext, the system is no longer IND-CPA secure. By "high quality", I mean But http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ |
@defuse we are 100% in agreement. When I said "such" high quality I was specifically referring to /dev/random and /dev/arandom. They should be cryptographically secure (as such /dev/urandom), but using a blocking source us overkill unless forward security is required (key material mainly). And yes, Rand needs to die... |
I'd rather not expose |
@@ -1428,6 +1449,7 @@ static void php_mcrypt_do_crypt(char* cipher, const char *key, int key_len, cons | |||
while (size) { | |||
iv[--size] = (char) (255.0 * php_rand(TSRMLS_C) / RAND_MAX); | |||
} | |||
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "RAND is not safe"); |
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.
If we find this undesirable it should be deprecated, not eternally spit out E_NOTICE errors,
/dev/urandom would be the default from PHP 5.6. Commit: fd5fbba Log: Also fixes the ARGINFO for mcrypt_create_iv() and adds missing |
@yohgaki That's good, but not good enough. https://github.com/search?l=php&p=1&q=MCRYPT_RAND&ref=cmdform&type=Code |
@defuse I agree. MCRYPT_RAND is better to be deprecated. |
This is the very definition of a change that needs an RFC. There needs to be documentation plans, rollout/phaseout plans, etc. With documentation for alternatives, etc. This is not something that should just be merged in without process... |
@ircmaxell I agree. There should be discussion. It would better to be documented first, then raise error. Raising error would start from 5.7 or later. |
https://wiki.php.net/rfc/deprecate_mcrypt_rand I've submitted a draft RFC for this |
#889 See also |