Is this algorithm demonstrating proof of work? This is a algorithm where a "token" is combined with a time stamp and then a cryptographic hash is generated from the combination, next the objective is to find a token whose hash will collide with N digits of the timestamp+token hash.

This operation is computationally intensive and requires work by the client. The resulting token is time sensitive and expires. This could possibly be used to deter a denial of service attack. or other brute force attacks.

What is this algorithm called? Is something similar in use? is it a demonstration of "proof of work"?

In the future, we generally ask that questions on Crypto.SE should use pseudocode to describe the algorithm concisely -- rather than giving a full implementation. Here the code makes it harder to understand what is going on, whereas you could describe the basic algorithm in one or two lines of simple mathematics. Just letting you know for the future....
–
D.W.Dec 20 '13 at 23:52

2 Answers
2

there is no need for the client-side to hammer /urandom. The odds of any subsequent random byte stream hashing to the same prefix are the same (actually worse) as the odds of any simple incrementing value.... i.e. you may as well change the urandom reference to just something++

A sophisticated client-side 'attacker' who knows the number of significant digit matches would be easily able to compute a rainbow-table of tokens that match the incoming digits. This ranbow-table will not take much longer to generate than the actual proof-of-work you require, and would be almost instantaneous to query.

All this process does is make legitimate access harder, and nefarious access fast.... ;-)

@kylek, I think you've misunderstood rolfl's answer. Rolfl is 100% correct on both of his criticisms, and I think you misunderstood his points and haven't fully grokked his critique yet. Maybe read it a second time? (Rolfl clearly does understand that this is for proof-of-work, not for authentication.)
–
D.W.Dec 20 '13 at 23:50

No. This is not a good design of a proof-of-work system. Your design involves the server providing a value $y$ and asking the client to provide $x$ such that $H(x)=y$ (where $H$ is a hash function truncated to a suitable number of bits). As rolfl explains, this is not adequately secure; it is vulnerable to precomputation attacks, e.g., Hellman's time-space tradeoff or rainbow tables.

The proper protocol is to have the client provide a random 128-bit value $r$ and ask the client to provide $x$ such that $H(r,x)=0$ (where again $H$ is a cryptographic hash function truncated to a suitable number of bits). That is secure against precomputation attacks.

Rolfl already made this exact point; I am just elaborating in more detail, since it appears you didnt quite appreciate his observation.