@MaartenBodewes What's wrong with rounding errors? The exact bit-for-bit outputs of all basic arithmetic operations (+, -, *, /, sqrt) are precisely defined for all inputs except NaN (and whether the output is a NaN or not, and what kind, is also precisely defined, just not the bits of the NaN payload). This has even been seen in crypto implementations like the first implementations of Poly1305.

@fectin If you do this in binary64 floating-point arithmetic (or x86 80-bit floating-point arithmetic, or binary128, or double-binary64) when the input is restricted to be an integer in [0, 2^31), the effect will be exactly the same as multiplying by two; the fact that you took an intermediate detour through some floating-point numbers in [0,1] is immaterial. Do you think 2*x makes a good PRNG?

The problem you're tripping over here is not that rounding errors are unpredictable; quite the reverse: under the false (but distressingly popular) premise that floating-point arithmetic is black magic, you've done some things that sound like random black magic in your head, and ended up with something trivially predictable because floating-point arithmetic is not, in fact, black magic, but actually a very predictable reliable computational system.

> AES, in principle, doesn't require well distributed keys.

@MaartenBodewes ???

@MaartenBodewes The answer you linked to support that is bonkers. There have been well-known attacks on nonuniform subspaces for more than a decade, like the related-key attack of Biryukov and Khovratovich. The security contract requires uniformly distributed keys, period.

This is terrible advice. You are inviting an unwary user to shoot themselves in the foot with related-key attacks that are normally not even worth any cryptographer's time to think about because it is so trivial to avoid them!

@SqueamishOssifrage agreed. In fact, if you re-read, you’ll see that I discovered this when I looked back at it. Fortunately, I was just looking for a repeatably-seedable hash with decent distribution and low predictability. That’s a much lower bar than “secure”.

If you’re curious, the specific thing is here: github.com/fectin/hexmap/blob/main/LCG.js

I’ve determined that it works well enough for my use case, and also that it’s totally unsuited for security.

If there’s another simple approach that fits the same use, but gives better results, I’d love to learn about it!

@SqueamishOssifrage Sure, the rounding errors are well defined. It is really more of a problem when floating point is used to perform calculations where both the input / output are integers. Much better to use integer calculations where possible for that.

@SqueamishOssifrage I'll check how much the related key attacks apply when e.g. part of the key is simply set to zero. Of course the attack would only be interesting if the attack would downgrade the security more than that the reduction of randomness does in the first place. Do you have a reference that shows the relation? But you are right, I should definitely not make overly broad statements like that.

@MaartenBodewes I doubt whether there is a reference for specifically the subspace you recommended. But that's not because it's secure; it's just that nobody would bother studying it. The security contract for a PRP is that the key must be chosen uniformly at random. No uniform random key, no security contract. End of story. Any specific attacks in the literature on particular violations of the contract are mainly of academic interest; point is: you're in breach of the contract.

@SqueamishOssifrage Interesting. I tried to find anything on the internet, but without success. I guess I'll have to dig out my copy of the design of Rijndael. I'll however remove my recommendation in the mean time.

What kind of bothers me is the fact that you say that nobody would bother studying it. If a cipher is used to implement a hash function it seems that it is worth studying it. I mean, isn't the related key attack for AES-256 proof that people are studying it?

I can't comment yet or would have posted that below the answer