MSC1974: Crypto Puzzle Challenge

[Zolmeister]

Crypto Puzzle Challenge

Proof-of-Work rate-limiting, via cryptographic puzzle challenge, to fight spam.

Proposal

New Errors:

• M_PUZZLE_NEEDED
  • extra field seed (String)
  • extra field bits (Integer)
  • extra field algorithm (String bcrypt)
• M_PUZZLE_INVALID

New Headers:

• X-Matrix-Puzzle
  • seed:bits:algorithm:n - where n is an integer
  • When this header is hashed with algorithm is must produce at least bits many leading zeros

In response to a request, the receiving party may error with a M_PUZZLE_NEEDED challenge, which requires a crypto-puzzle be solved and request re-submitted with proof-of-work attached as X-Matrix-Puzzle.
The puzzle is solved by incrementing n and re-hashing the header using algorithm, then checking for leading zeros.

Inspired by Hashcash

Tradeoffs

The original Hashcash is not a request-response challenge but instead only opt-in by the sender. This allows for pre-computation and does not allow dynamic bits to be requested (necessary as computers get faster) or a change in algorithm (again, necessary because of dedicated hardware (ASICs)). Though it could be made viable by re-specifying these in the Matrix spec.

bcrypt is used here but there are other options e.g. Argon2d, scrypt. bcrypt was chosen because it's popular (and thus most software ecosystems should have a package for it) and because it is hard to parallelize on GPU/ASIC hardware.

Potential issues

Giving clients free-reign over when to use the error and how much work they require could lead to some unintended consequences.

E.g. If the major server implementations use too high values as their default then it might force out low-end hardware altogether (and make running your own server potentially costly (in CPU time), decreasing decentralization).

Client battery will also be severely impacted if puzzles are overused

Conclusion

This proposal provides a powerful spam-fighting mechanism which relies on compute resource consumption.

Signed-off-by: Zolmeister zolikahan@gmail.com

[uhoreg]

Is this intended for client-server interactions, server-server interactions, or both?

[Zolmeister]

Both

[JJJollyjim]

A major consideration you don't mention here is power consumption, both from the perspective of an end user ("I have to use whatsapp instead of riot because riot kills my battery") and from an ethical perspective: ("whoops, matrix now uses more energy than a small country").

Sticking to the first point, is it really possible to pick a difficulty such that a user on a low-end smartphone or a tiny microprocessor on a battery-powered IoT device sees no impact, while an attacker with desktop GPUs (or worse) is severely impeded?

Overall, I can't really see the need for this: can you explain how your proposal solves problems that traditional "come back in ___ seconds" rate limiting (based on IP or user account) doesn't?

[Zolmeister]

@JJJollyjim Excellent points, battery life added to issues
That's also a strong argument for specifying a correct mode of operation for when to serve the error.

Perhaps the biggest difference from "come back in ___ seconds" is the ability to rate-limit initial connections. For example the first connection from an unknown IP address / user. This makes this method significantly stronger against distributed attacks using multiple IP addresses.

I suspect that IoT devices would use a federator that did not challenge them with a PoW. Otherwise this may actually be a positive given the threat of IoT botnets.

I posit that even a small proof-of-work would deter spammers in favor of a cheaper target.

[stefnotch]

A major consideration you don't mention here is power consumption, both from the perspective of an end user ("I have to use whatsapp instead of riot because riot kills my battery") and from an ethical perspective: ("whoops, matrix now uses more energy than a small country").

I think that could be solved by servers only asking for a proof of work when connecting for the first time or when sending the first few messages. Normal users don't join a server all that often, so it shouldn't cause much of an overhead.

However, lots of spambots these days will join a lot of servers and immediately send a lot of spam messages. With a proof of work approach, that would make sending spam more costly.