sfmt-erlang security notice 8-JAN-2020: regarding the Ambionics Security's PHP mt_seed() vulnerability
Thu Jan 9 05:41:38 CET 2020
I've discovered it's not only PHP or sfmt-erlang, but any language or
system which uses the reference initialization sequence (i.e. copying the
init_gen_rand() of MT or SFMT distribution by the original authors) might
be affected by this PRNG state disclosure.
-- Kenji Rikitake
On Wed, Jan 8, 2020 at 7:19 PM Raimo Niskanen <
> 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
> > 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
> > 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
> > `mt_rand()`](https://www.ambionics.io/blog/php-mt-rand-prediction) on
> > 6-JAN-2020. sfmt-erlang uses the same seed-to-internal-state
> > 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions