Richard Clayton

There doesn't appear to be any discussion on your website or on GitHub about why, to be blunt, this is even a good idea in the first place. A classic 2004 paper, "Proof-of-Work" Proves Not to Work [0], explained that the fundamental problem with proof-of-work bot filters is that attackers will always be able to solve the cryptographic puzzle faster than legitimate users. A touch of security-through-obscurity can help at the margins, but you chose Blake2b, which is used by cryptocurrencies like Zcash, Siacoin, and Nano [1], and as a result there are optimized GPU algorithms (first Google result [2]) and FPGA designs (one of the top Google results [3]). Have you run the numbers on any of those? The closest to any discussion of these numbers that I saw was a mention on your website that it may take up to 20s on mobile; for comparison, the much-hated image CAPTCHA takes about 6-12s on average for native English speakers, and 7-14s for non-native speakers [4]. In another comment you bring up the idea of starting with a lower difficulty, and increasing it with repeated requests from the same IP address (IPv4, I assume). Unfortunately, access to unique IPv4 addresses is highly correlated with access to more compute power: laptops and desktops in developed countries are most likely to be in a household with a unique IPv4 address, whereas mobile devices on 4G internet and households in developing countries are more likely to be behind Carrier-Grade NAT [5], where thousands or…

Here are a couple examples of physical access leading to key extraction. You're welcome to be pedantic (those are side channel attacks, they don't defeat the boundary!) but one way or another, physical access wins. https://www.cl.cam.ac.uk/~rnc1/descrack/ https://ninjalab.io/eucleak/

There's this paper from 2004: "Proof-of-Work Proves Not to Work": https://www.cl.cam.ac.uk/~rnc1/proofwork.pdf The conclusion back then was that it's impossible to make a threshold that is both low enough and high enough. You need some other mechanism that can distinguish bad traffic from good (even if imperfectly), and then adjust the threshold based on it. See, for instance, "Proof of Work can Work": https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/lui-pow.pdf

Proof of work proves not to work (2004) https://www.cl.cam.ac.uk/~rnc1/proofwork.pdf

I think there's some confusion. Are you sure that you are talking about the same thing? What I meant here is a real HSM, something similar to a IBM 4758 [0] (which was once vulnerable, but only because it had buggy software), not a SIM card or a credit card chip. Do you imply that many HSMs are based on the same Gemalto chip? [0] https://www.cl.cam.ac.uk/~rnc1/descrack/ibm4758.html

The standard response to proof-of-work spam deterrents is that "significant numbers of senders of legitimate email would be unable to continue their current levels of activity"[0]. While I don't think that's necessarily a bad thing, it does limit the utility of such a service. [0]: https://www.cl.cam.ac.uk/~rnc1/proofwork.pdf

I'd like to see more analysis of things like CHAFFINCH. https://www.cl.cam.ac.uk/~rnc1/Chaffinch.html

Sounds a bit like a simplified "Chaffing and Winnowing"[1], where the chaff identification is pre-shared through your custom compression parameters. There was a HN story[2] on Chaffinch[2], which is where I came across teh idea. [1] https://en.wikipedia.org/wiki/Chaffing_and_winnowing [2] https://news.ycombinator.com/item?id=14408757 [3] https://www.cl.cam.ac.uk/~rnc1/Chaffinch.html#Chaffing

Ah yes, another person new on the Internet. Welcome. The blogger doesn't seem to be aware that this is an old idea, dating back to 1992 or earlier (well before the also old 1997 date given in WikiPedia for HashCash). See the references in this paper: http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf

In the UK, BT (The biggest ISP) introduced CleanFeed[0] and "strongly encouraged" (read forced) to be used by the government. It was claimed that it would only ever be used for blocking child sexual abuse imagery. Recently a judge has ruled that BT must use the same system to block a website used to share links. [1] The list of blacklist sites itself can only be edited by a small group (iirc 4 people) of unelected and unaccountable people at the IWF[2] Cleanfeed is also pretty flawed, doesn't work with HTTPS, can be interrogated to get a list of blocked content (using TTLs) and misleadingly returns 404 for blocked content. [0] http://en.wikipedia.org/wiki/Cleanfeed_%28content_blocking_system%29 [1] http://arstechnica.com/tech-policy/news/2011/07/british-telecom-ordere… [2] http://www.iwf.org.uk/ [3] http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf

Customer requests are redirected by ISPs to the transparent proxy on an IP:port basis. DNS is not poisoned; using a different DNS will not affect how it works. http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf I personally use a cheap VPS located in the US to get around IP geolocation (e.g. occasional Youtube videos, Hulu etc.), and it can also circumvent this, though I have never had cause to - my Be Pro account does not block filesonic.com, for example.

Interesting paper on this subject, mentioned in the article: http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf

It's not the same chip, but you can read about some of the more common high-end countermeasures on this page: http://www.cl.cam.ac.uk/~rnc1/descrack/ibm4758.html

I thought the GFW worked by sending a RST to any TCP connection that it didn't like. If you ignore the RST then the connection goes ahead. Has that changed? http://www.cl.cam.ac.uk/~rnc1/talks/060628-Ignoring.pdf

If sending mail requires CPU cycles, then spammers will steal cycles. If it requires real money, spammers will steal that. http://www.cl.cam.ac.uk/~rnc1/proofwork2.pdf

Ben Laurie posted a link to this paper in response to Satoshi's posting his first version of Bitcoin[1], with this comment: > Richard Clayton and I claim that PoW doesn't work: > http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf It's in the context of a discussion about why PoW-based tokes are a bad idea in terms of burning CPUs and their carbon footprint. The generous interpretation is that he was claiming that this discussion was moot because the bigger issue was that PoW wouldn't actually work as a feature of Bitcoin. The less generous (but probably accurate) interpretation is that he posted that without reading either the Bitcoin whitepaper itself or the abstract of the whitepaper. IIUC his paper is about how PoW applied to email would either break a lot of the desirable features or the difficulty would be too low to prevent spam. I'm not sure why this bothers me enough to post about it on HN-- I'd actually prefer it to be true and Bitcoin fanbase never to have existed. Nevertheless, his paper wasn't really relevant to that discussion and I'm not sure why he posted it there. 1: https://www.mail-archive.com/[email protected]/msg10225.html Edit: clarification