Before I respond, here’s one more data point: I’ve compiled OpenSSL 1.0.2 for ARM and got ~60,500 SHA-256 hashes (it’s close enough to not matter to the result for HMAC-SHA-256) per second.
That says that assuming 1 second as the “reasonable” time to solve a puzzle, we can expect to do about 16-17 bits for one solution, 12 for 16 solutions or 10 for 64. That’s pretty much in line with what I got with “my” code. According to messages on openssl’s dev list, the assembly-language version of SHA-256 is about twice as fast, so respectively that’s 18, 13 or 11 bit puzzles, Still 3 bits behind Intel. This does not take into considerations 2- or 4-core laptops or octo-core Samsung Galaxies. > On Feb 5, 2015, at 8:52 AM, Valery Smyslov <[email protected]> wrote: > > I think this data proves the idea that the difference between > computation power of different clients is significant and > no single puzzle difficulty level would be reasonable for all. > I think we should proceed with the proposal that > client is allowed to return less zero bits than requested. It’s simpler and safer code to get a request from the initiator, mark it as solved/not-solved, and process if solved or discard if not. Then you don’t have to do any queueing beyond what the UDP stack is doing anyway. > And in this case we may go further. > The server may even not indicate to the client > how many zero bits it wants to get. The server > could just give the puzzle to the client and > the client would return the best solution that it can > get for a reasonable (from client's point of view) time. > Some clients would be able to get more zero bits, some less. > Then the server would sort all the requests, as described > in Tero's e-mail and serve them accordingly. This would allow a sufficiently powerful botnet to flood the queues and deny service to phones. Suppose it turns out that phones like to work for 0.5 seconds and usually come up with 15-, 16-, or 17- bit solutions, it should be easy for a botnet to work far less time on each puzzle and solve hundreds of puzzles at these bit lengths. That would effectively block the phones that take a whole half second to calculate just one such solution. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
