sfmt-erlang security notice 8-JAN-2020: regarding the Ambionics Security's PHP mt_seed() vulnerability

Raimo Niskanen raimo+erlang-questions@REDACTED
Wed Jan 8 11:19:18 CET 2020

On Wed, Jan 08, 2020 at 01:03:53PM +0900, Kenji Rikitake wrote:
> The following is the security notice of sfmt-erlang, a random number module
> for Erlang based on SFMT, regarding the recently revealed attack against
> PHP mt_seed() vulnerability.
> I've already updated hex.pm/sfmt with a new package including the following
> security notice.
> -- Kenji Rikitake
> ## Security notice regarding the PHP mt_seed() vulnerability

Great that you keep an eye on these kinds of matters, Kenji! :-)

> Ambionics Security published [an internal state retrieval algorithm of PHP
> `mt_rand()`](https://www.ambionics.io/blog/php-mt-rand-prediction) on
> 6-JAN-2020. sfmt-erlang uses the same seed-to-internal-state initialization
> algorithm at the function `init_gen_rand/1`.
> For reducting the possibility of the internal state revelation, use
> `init_by_list32/1` instead, better combined with `rand:uniform/1`. [Raimo
> Niskanen published a piece of code for this purpose](
> http://erlang.org/pipermail/erlang-questions/2018-July/095875.html).

I would just like to emphasize that using `rand:uniform/1` with any algorithm
in the `rand` module only _reduces_ the possibility for internal state
revelation.  All the steps in that Ambionics Security paper, as far as I
can tell, can, in theory, be done on any algorithm in the `rand` module, 
albeit with much more work. Not yet figured out work, to be added...

"Breaking" a non-secure PRNG like a Mersenne Twister is really a moot point
since you can not break what is not supposed to hold.  The Ambionics
Security paper shows code that incorrectly used a non-secure PRNG to
generate a password and then demonstartes exactly how efficiently that
can be exploited.  So what they actually broke was that incorrect code.

> *Note well that sfmt-erlang has no cryptographic security guarantee and
> MUST NOT be used for security purposes such as password generation.*

_That_ is a very important point here!

> Also: Version 0.13.0 and 0.13.1 Erlang and C code files are identical.
> Users have no need to upgrade.


/ Raimo Niskanen, Erlang/OTP, Ericsson AB

More information about the erlang-questions mailing list