Skip to content

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

Closed
wants to merge 3 commits into from

Conversation

yohgaki
Copy link
Contributor

@yohgaki yohgaki commented Feb 3, 2014

  • Add /dev/arandom support
  • Raise error for dangerous usage

@defuse
Copy link

defuse commented Feb 21, 2014

+1000. I really hope this gets merged.

random_source = "/dev/random";
break;
default:
random_source = "/dev/random";
Copy link
Contributor

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 :)

Copy link
Contributor Author

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.

@ircmaxell
Copy link
Contributor

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...

@defuse
Copy link

defuse commented Mar 2, 2014

@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 /dev/urandom, not /dev/random. I'm not exactly sure what /dev/arandom is, but it should just use /dev/urandom. If that's what you meant, then I agree. There's no need for /dev/random when you're generating an IV.

But RAND needs to die. It's not safe to generate an IV with that.

http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

@ircmaxell
Copy link
Contributor

@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...

@realityking
Copy link
Contributor

I'd rather not expose /dev/arandom to userland. PHP should strive to abstract these differences away. If I really, really need to access it I can always fread() from /dev/arandom.

@@ -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");
Copy link
Contributor

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,

@yohgaki
Copy link
Contributor Author

yohgaki commented Mar 11, 2014

/dev/urandom would be the default from PHP 5.6.
I think this is good enough.

Commit: fd5fbba
Author: Nikita Popov [email protected] Tue, 11 Mar 2014 13:42:16 +0100
Parents: a117e6b
Branches: PHP-5.6 master

Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=fd5fbba98cdc800c9f25b6213ed72bd24792ecde

Log:
Use /dev/urandom as the default mcrypt_create_iv() source

Also fixes the ARGINFO for mcrypt_create_iv() and adds missing
UPGRADING entries.

@yohgaki yohgaki closed this Mar 11, 2014
@defuse
Copy link

defuse commented Mar 11, 2014

@yohgaki That's good, but not good enough. MCRYPT_RAND needs to be deprecated, too. There's craploads of code using MCRYPT_RAND thinking it's safe when it's not:

https://github.com/search?l=php&p=1&q=MCRYPT_RAND&ref=cmdform&type=Code

@yohgaki
Copy link
Contributor Author

yohgaki commented Mar 11, 2014

@defuse I agree. MCRYPT_RAND is better to be deprecated.

@ircmaxell
Copy link
Contributor

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...

@yohgaki
Copy link
Contributor Author

yohgaki commented Mar 12, 2014

@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.

@sarciszewski
Copy link
Contributor

https://wiki.php.net/rfc/deprecate_mcrypt_rand

I've submitted a draft RFC for this

@sarciszewski
Copy link
Contributor

#889 See also

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants