2

As the title, if I have:

  1. A stream of 1D noise

And I know:

  1. The noise is generated using the Perlin method with a known number of octaves > 1. (as implemented here)

  2. The random numbers used in each call to the Perlin noise method are generated using the Mersenne twister.

  3. The Mersenne twister is initialised with the same seed in every call.

Is it possible to attack the state of the random number generator and therefore predict future noise?

I know that some steps in this process are vulnerable. But when combined, can this still be attacked?

perlin_secure
  • 29
  • 3
  • What is "every call" in this context? Is it "whenever I call getPerlinRNGOutput I get the same numbers"? – SEJPM Dec 14 '19 at 12:32
  • A super quick test to determine whether or not something is completely broken is to run some stats on the outputs of the algorithm. If the output doesn't behave the same way a uniformly random sequence of bits is expected to, then it is surely broken. (Note, that does not hold the other way around, if the output did look uniform that does not mean it is secure). – Ella Rose Dec 14 '19 at 16:05
  • The perlin noise implementation uses an array of pseudo-random numbers that is initialised during the first call. Once initialised, every call to the function is completely deterministic. – perlin_secure Dec 15 '19 at 16:53

1 Answers1

2

First of all, the Perlin method requires a random number generator as input. It seems deterministic in nature by itself. So if the random number repeats with a given seed, then I suppose it should always generate the same stream. In that case it is insecure as it is predictable even without any particular attack. Besides that, if the seed is a predetermined value then it could be considered a constant in the derived MT algorithm, and it would therefore go against the Kerckhoff principle.

As the Perlin method is not strictly made to be irreversible, I don't see how it would protect an insecure PRNG. For instance, I would expect that it generates certain maximum and minimum values for which the output of the random number generator can be established. If that happens for enough bits, then in the end enough state of the Mersenne Twister may be known to retrieve the seed, breaking any security present in the combination of the two algorithms.

Let's assume that the Perlin method at least leaks some information about the stream. In that case the question becomes: can you break the Mersenne Twister given enough output, even if that output is further apart? And that question I don't know the answer to; I would however not assume that it is impossible.

However, things will get worse: if the Mersenne Twister only uses a 32 bit seed and the Perlin method is indeed deterministic, then it is completely feasible to try all possible seed values and simply run the algorithms on them, comparing the output against known values. And as the 32 bit strength of the seed is nowhere near enough security, the algorithm would not just be theoretically but also practically broken as it would be easy to brute force the seed.

Practically this would require you to know the parameters of the specific Perlin noise generator as well, of course. Again, considering those secret would go against Kerckhoff's principle, so theoretically it would still not be secure even if those have enough strength to secure the implementation.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • Er, the Twister has a state size of thousands of bits. How have you inferred that it's only seeded with 32? That figure's not in the question. – Paul Uszak Dec 15 '19 at 01:05
  • 1
    Checked the original source code of the creators. Also uses 32 bit seed - even ANDs with 0xFFFFFFFF. Pseudocode and other implementations I've seen also use 32 bit seed. So there we are, unless they changed the algorithm and initialized the state differently, it seems to have a 32 bit seed (and if you look closely, there is a guardian if before the claim of a 32 bit seed :) ). – Maarten Bodewes Dec 15 '19 at 01:49
  • The code that was linked to (in the question) also uses a 32 bit seed, by the way. I haven't done a full review and there seem to be two seed methods though. – Maarten Bodewes Dec 15 '19 at 17:17