3

I have been following information on SO about generating random strings using mcrypt_create_iv() and have some example code over at 3v4l.org.

After reading the PHPWiki all mycrypt_* functions will show a depreceated warning but it does not specify what will be used in 7.2/8.0 that replaces these functions.

Since it states it will be removed in 7.2/8.0, what will be used to replace IV's?

I do not use this function in my software for encryption and decryption. I only use it for safe/retrievel of a unique string.

Jaquarh
  • 6,493
  • 7
  • 34
  • 86

1 Answers1

4

random_bytes()

Although I imagine each PHP cryptography extension would provide its own version of a function to generate random data, like they currently do:

That is simply because any cryptography API would be incomplete without access to a CSPRNG. In fact, mcrypt_create_iv() was added by the PHP developers for that same reason, while it is otherwise not part of libmcrypt.

I only use it for safe/retrievel of a unique string.

"Random" doesn't mean "unique". The former needs to be unpredictable, while the latter has to be unrepeatable.
It is true that the chances of a collision decrease exponentially with each random byte you add to a string, but uniqueness is never 100% guaranteed.

Narf
  • 14,600
  • 3
  • 37
  • 66
  • This is perfect, I like how you touched on the *unique* keyword in my question. It's the whole *read lock's* that are bugging me, but the chances of this **IV** ever being repeated at the *same time* as another user is close to 0.0000(n)1% I assume? So as long as we check database entries, this should be close to 99.9% guaranteed to prevent read locks? (+1) see [test code](https://3v4l.org/mgeUq) for example. – Jaquarh Nov 05 '16 at 15:11
  • @KDOT what are you trying to achieve exactly? The purpose of IV is not to be unique. It's purpose is that you use it when encrypting data to produce different cyphertext even if underlying data is the same. That's used to prevent decryption attempts. It seems you're trying to use it for something else - if you can explain the real problem, I'm sure there will be sufficient answers to help you with that. If my hunch is correct, you're going to do something that might "hurt" later. – N.B. Nov 05 '16 at 18:08
  • It's for a salt on user hashing, salts need to be complex but unique @N.B. – Jaquarh Nov 05 '16 at 18:19
  • @KDOT then you should be using [password_hash](http://php.net/password_hash) instead of rolling your own solution with IV. – N.B. Nov 05 '16 at 18:19
  • Yes but then if you look into the options, you can set an IV. Since `mcrypt_create_iv()` is depreciated and soon removed, I was looking for a replacement IV for using in the `password_hash()` options param @N.B. – Jaquarh Nov 05 '16 at 18:22
  • You can't set an IV. You can set **salt** and you can also see in the red box that it's better to simply use salt generated by default. You can't make it do anything better if you provide salt generated on your own compared to what the function does by default. – N.B. Nov 05 '16 at 18:26
  • I too thought you were using this function for the wrong purpose, but it turns out you're using it correctly, just for the wrong reasons, lol. IVs and salts only differ in what they are used for, but are otherwise the same and need to be *unpredictable*, not unique. But speaking of `password_hash()`, it's 'salt' option is also deprecated and it just so happens I recently answered a question about that too: http://stackoverflow.com/questions/40351479/php-salt-option-to-password-hash-is-deprecated/40378435#40378435 – Narf Nov 05 '16 at 18:47
  • I generate a random unpredictable salt and use the `hash()` method with `SHA256`. I then store this salt corresponding to that user in the database so next time he/she wants to log in, I hash the password using the same salt (unique) and check the hashes match. Am I doing it wrong, should I be using `password_hash()` over `hash('SHA256', 'salt' . 'pass');` ? @Narf – Jaquarh Nov 05 '16 at 23:01
  • Yes, you should be using the `password_*()` functions. – Narf Nov 05 '16 at 23:54