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

[Kenji Rikitake]

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 <
raimo+erlang-questions@REDACTED> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200109/8f9ba041/attachment.htm>