基于生命游戏的hash函数改进（续1）

上一篇文章：网页链接

外网的资料

能科学上网的同学可以直接看外网资料。
reddit的讨论
以下是讨论的复制版，我尽可能的还原讨论的层次结构。

---

Posted by u/kendfrey 4 years ago
How secure is Conway’s Game of Life as a hash algorithm?
Conway’s Game of Life is very much like a hash algorithm, in that any given output can be produced by many inputs. You could create a Life grid based on, say, a password, and step it forward by a couple million generations. This would generate a “hash” that could be used to verify the password.
Obviously Life isn’t designed as a hash algorithm, much less a cryptographically strong one. But reversing Life is a hard task. Are there any simple flaws that prevent it from being used as a secure hash (purely for fun, of course)? Easy glider synthesis is the first one that comes to mind. I don’t know if that’s enough to cheaply generate hash collisions.
Even in the case where there are no shortcuts to generating collisions, there is still the problem of computational power. A good secure hash takes just as long to brute-force test one password as it does to verify the correct password. I imagine Life allows many ways to shortcut brute-forcing by terminating early. I can think of a few: Checking for escaping spaceships or lack thereof; Stable patterns. In real life security, a hash algorithm that takes one second to check a password makes for exceptional security. Does anyone know roughly how much computation would be required for similar levels of security using Life? I suspect it’s a lot more.
Is there anything published on this topic? Google wasn’t too helpful.

Ramin_HAL9001 4 years ago · edited 4 years ago
Most life reaches a stable state after a few steps, even if you allow gliders to wrap around edges. It would be hard to choose a good number of steps to run the game to produce the best hash.
Also, life boards tend to have an overabundance of zero-valued cells once the board reaches a stable state, so there would be many collisions, unless you had a reliable way of halting iterations before the board reached a stable state.
So I think for these reasons, CGoL is not really a secure hash at all.

kendfrey 4 years ago
Yes, this does appear to be a significant problem.
I think increasing the size of the grid and reducing the number of generations would probably help avoid the problems with stable states. It wouldn’t fix the problem, but it would help a little.

frezik 4 years ago
The Game of Life can implement a Turing Machine:
http://rendell-attic.org/gol/tm.htm
In theory, you can implement any cryptographic hash algorithm you want.

moschles 4 years ago
Conway’s GOL is absolutely terrible for cryptography.
Reasons:
A hash collision can be easily constructed. So easily, it could plausible be done with paper-and-pencil.
Compare this property to professional hash functions. Even with supercomputers, nobody has ever found a collision in SHA-512. (I reckon no known collisions have ever been found in SHA256. Though don’t quote me.)
The dealbreaker with Conway GOL is that it maps many different messages into the same digest. A so-called “collision”. This happens because a whole myriad of adjacent states will map into the same state. There are many localized states of GOL which map into the “all dead” state.
Nobody expects a hash function to be “perfectly” 1-to-1. That’s actually impossible even. But a hash function should seek this ideal rigidly – within reason.
There may exist a suitable cellular automata for a hash function, but it is not Conway’s GOL.
If you are seeking a CA for hash functions, I would highly suggest you poke around in grids that have enormous amounts of states (say like, 232 states per cell). The function applied should involve addition (modulo 232 )
XOR
bit rotations
Substitutions of bytes using a 1-to-1 table.
scrambling the “neighbors” between cycles. That is to say, you move the links to different neighbors after each cycle. In short, think outside of the traditional Moore Neighborhood.
Most importantly, make sure your Garden-of-Eden state is decorated with lots of constants that are independent of the message. So your GOE state will contain the ASCII password, lain alongside cells holding lots of weird constants. These are sometimes called “round constants”. They can be openly hardcoded in your source without loss of security. Take a short look at the sourcecode for WHIRLPOOL. It has enormous tables of these constants. Your grid will be doing the job of mixing these constants with the pass phrase.
Your final output should do (something along the lines of ) taking the parity bit of cell values.
https://en.wikipedia.org/wiki/Parity_bit

kendfrey 4 years ago
A hash collision can be easily constructed. So easily, it could plausible be done with paper-and-pencil.
Are you talking about a collision attack, or a preimage attack? Even if a collision attack is easy, it doesn’t appear that a preimage attack would be.

jimm 4 years ago
To avoid stable states, you could “salt” the password with some pattern of gliders or other creatures that would make that less likely. If each password gets a different salt that would also reduce clashes, wouldn’t it?

kendfrey 4 years ago
Salting is definitely something that I would use with this, as with all password hash algorithms.

charlieb 4 years ago
iirc Wolfram mentions the use of 1D CAs as hash functions in A New Kind of Scienve. A quick google gives these two results which may or may not be helpful (tl;dr).
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.8559&rep=rep1&type=pdf
https://info.cis.uab.edu/yzheng/publications/files/pkc98-cellularhash.pdf

ketzu 4 years ago
There are many game states that allow for easy collisions: All empty, still or periodic game boards. You’d need to prevent those states and then the question still remains: How hard is it to compute a possible previous state (as we do not need the actual original state)?

[deleted] 4 years ago
Wouldn’t it have to be a possible previous state from n generations ago, with n the same as the number of generations used for the hash? Assuming null, still, and periodic boards were prevented, as you say.

LagrangePt 4 years ago
I think the game of life has too much entropy - and by that I don’t mean chaos, but loss of energy over time. A large number of inputs will map to a much smaller number of outputs.

absrd 4 years ago
Collisions aside, my first thought went to Gosper’s Hashlife algorithm which simplifies the task of a brute force attack.

FaiIsnaiI 4 years ago
I think your idea is really intresting!
To resolve the problem of stable states I thought of this; make a meta-game of life, where each iteration consists of building a game-of-life gamestate and running it a bunch of iterations.
Making the gamestate could be done by for every cell, take the x-or of that same cell after the previous meta-iteration and the one before that; S[n,x,y] = S[n-1,x,y] XOR S[n-2,x,y] where n is the meta-iteration number.
While a more complicated function will cryptography be better, this should be enough to solve the issue.

kendfrey 4 years ago
Since the original grid is just a password represented in a Life grid, this is logically equivalent to storing a cleartext password instead of a hash. The whole point of a cryptographic hash is to scramble the input in a deterministic and irreversible way, which Life also does, for the most part.