There is a reason why MHFs cost a lot of memory instead of, sayfor example, CPU cycles. [[Bitcoin]] used repeated evaluation of [[SHA-2]] function as proof of work, but it turned out that modern general-purpose processors, i.e. off-the-shelf [[central processing unit|CPUs]], are very inefficient when tasked to compute a fixed function overmany andtimes over. MinersFor example, miners adopted [[application-specific integrated circuit]]s (ASICs) and achieved 10^16 speedup. While this is fine for what Bitcoin is good for, we want a more "egalitarian" hardness measure was needed. In other words, wethey wantwanted everyone to be equally inefficient in computing the function even if they have an ASIC. Because if some people can evaluate the function efficiently and some can't, then in order to make the function relatively hard for the short-cut takers, wethe will makemade the function too hard for a regular user. If everyone is inefficient, then everyone can evaluate a moderately-hard function.
Over time, it has been recognized that memory cost remains fairly equal across the board. Hence MHF.
Line 18:
== Variants ==
Based on their evaluation patterns, MHFs can be put into two camps: data-dependent (dMHF) and data-independent (iMHF). dMHFs are MHFs that which sometimes you don't know which pieces of information youare would still needneeded for later calculations, and iMHFs are ones thatwhere there's is no such ambiguity. <!-- this is probably a very confusing explanation, need to change! --> Examples of dMHFs are [[scrypt]] and [[Argon2]]d. Examples of iMHFs are [[Argon2]]i and [[catena (cryptography)|catena]]. Many of these MHFs are developed to be used as [[key derivation function|password hashing function]]s exactly because of their memory hardness.
dMHFs have the glaring problem that they are prone to [[side-channel attack]]s like cache timing. People tend toward iMHFs for this reason, especially for password hashing. However, iMHFs are mathematically proven to have weaker memory hardness properties than dMHFs.
