Disclaimer. I have asked a similar question on Electronics StackExchange: they advised me to try here.
The question
I am in the process of developing a simple protocol whose security relies on the assumption that computing the SHA256 hash of a very long string of bytes x takes a long amount of time. Intuitively, even a massively parallel adversary can only compute SHA256(x) by successively feeding each chunk of x into SHA256, which takes a long time.
Now, in implementing my protocol in the real world, I need to put constants to this intuition. Which leads me to the question:
How quickly can we compute the
SHA256hash of a long stringx?
More precisely, let us assume that the length of x is, e.g., 1 GB. Given our current / foreseeable level of technological development (this includes both algorithms and hardware), how quickly (in seconds) can an adversary realistically compute SHA256(x)?
To the best of my current understanding, ASICs represent probably the answer to my question: by designing application-specific circuitry, one can speed up even computations that are not easy to parallelise, e.g., on a CPU. However, I am not aware of how quick ASICs can get. This is why I originally asked this question on Electronics StackExchange.
More details
I am aware that this question has been previously asked on Crypto StackExchange here. However, that question is three years old, and technology advances constantly. More importantly, that question does not seem to address ASICs! The only answers there concern CPUs for SHA256, or ASICs for SHA3 (which is actually designed, as far as I understand, to be sped up with dedicated hardware).
The protocol I am working on is a super-simple design for Proofs of Space: one plots some large portion of its memory, others can quickly verify that the plot is correct (with high probability). My scheme relies on repeated hashing to plot, so what I am looking for is a hash function that satisfies the following:
- As fast as possible: the faster the hash function, the faster and simpler the plotting.
- As egalitarian as possible: the speed ratio between the fastest possible implementation of the hash function and standard, CPU-based, market-available implementations should be not much larger than $1$
This is why I am inquiring about
SHA256: it is reasonably fast, and I know that it is already accelerated in standard x86 CPUs, which (I suppose) can reduce the gap between CPU-based and ASIC-based implementations.
