# Is this SHA256 hash implementation secure from rainbow table, brute forcing attacks?

So I have an implementation where by we have an $8$-byte random input (entirely random, not user defined) which we hash with $\text{SHA256}$. The hash is shared with many parties to the point that we consider it is effectively public, so we are concerned with potential attacks to reverse the hash.

With this input, there are $1.8 \times 10^{19}$ hashes.

So my calculations for brute-force feasibility are done taking into account reported hash rates of bitcoin mining rigs and ASICs from:

https://en.bitcoin.it/wiki/Mining_hardware_comparison Current best $7,722,000$ MHash/s would take 27 days ($\frac{1.8 \times 10^{19}}{7722000000000 \times 60 \times 60 \times 24}$).

https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison Current best $2,568$ MHash/s would take 227 years ($\frac{1.8 \times 10^{19}}{2568000000 \times 60 \times 60 \times 24 \times 365}$).

Also, I'm assuming that since bitcoin mining is $\text{SHA256}(\text{SHA256}(x))$, that either the times above could be roughly halved, or in the case of an ASIC which may not be flexible enough to do single hashing, a brute force attempt would simply target $\text{SHA256}(target_{hash})$ instead?

As for calculating the rainbow tables, I'm guessing at the basic level, each record would be $40$ bytes ($8$ byte input + $32$ byte hash), leading to $1.8 \times 10^{19} \times (8 + 32) = 7.2 \times 10^{20}$ bytes $= 720,000,000$ terabytes

I've made a number of brain farts in getting to these numbers, so I'm not entirely confident in their accuracy, and whilst I've read many articles on the related topics, my concern is that they all seem to target password cracking, and therefore don't assume that $8$ bytes input is actually $8$ bytes of entropy, especially since they often promote dictionary attacks.

Please can anybody confirm the accuracy of the above numbers and whether my methods are sound?

Rainbow tables should allow for quick breaks of the security and normally reduce the storage required to $2^{2n/3}$ and the computational requirements to $2^{2n/3}$ per look-up or more generally, given $2^m$ storage, the lookup time will be around $2^{2(n-m)}$.
If you want to defend against rainbow tables, salts are inevitable, because you need a full rainbow table per unique salt, which is computationally and storage-wise intense. As for the efficiency of rainbow tables, you need a full pass over the complete space (all $2^{64}$ values) to build the table. For the original (first) publication of rainbow tables, see "Making a Faster Cryptanalytic Time-Memory Trade-Off" by Oechslin (PDF)