EdDSA, Ed25519, Ed25519-IETF, Ed25519ph, Ed25519ctx, HashEdDSA, PureEdDSA, WTF?
A slightly unfortunate trend in protocol design has been to prepend rather than append &quot;info&quot; fields to hash inputs. In other words, we tend to see<p><pre><code>    H(info || msg)
</code></pre>
instead of<p><pre><code>    H(msg || info)
</code></pre>
There are some good reasons to prefer append to prepend. One practical reason is that---related to what&#x27;s discussed in the article---if we have to compute two values<p><pre><code>    H(msg || info_1)
    H(msg || info_2)
</code></pre>
we can do this with just one pass over msg (though admittedly in a non-blackbox way, namely, by saving an intermediate state of the hash computation). In contrast, for a well-designed hash function there should not be any way to save work when computing<p><pre><code>    H(info_1 || msg)
    H(info_2 || msg)
</code></pre>
and this lack of work savings is one of the reasons we tend to get prehash modes.<p>In addition, prepending to msg comes with a range of subtle security issues. As an example, for Merkle-Damgaard hashes like SHA-2 a proper prefix design needs to pad the prefix to a multiple of H&#x27;s block length. This is to ensure that msg starts on a block boundary, which means that the hash digests as much of msg as possible in a single invocation of the compression function. Otherwise, if msg is short and it gets broken across a block boundary, this can make meet-in-the-middle--style attacks easier.<p>In contrast, appending the info string guarantees that msg starts at a block boundary, which is a small nicety. Moreover, one can easily guarantee in a black-box way (and independent of the value&#x2F;encoding&#x2F;&amp;c of the info string) that msg <i>ends</i> at a block boundary (just by padding msg). This can be useful as a defense against some kinds of power analysis in the case that msg is a secret [1].<p>To be sure: appending also requires care---and care is always required when a Merkle-Damgaard hash! (Sponges like SHA-3 are more resistant to misuse.) At the very least, whatever is appended to msg should be prefix-free, and you will likely want to stop length extension attacks and related issues (see [2] for further discussion of this).<p>But in general my take is that the set of footguns for append is a subset of the prepend ones, and I hope that more folks go towards appending in the future.<p>[1] <a href="https:&#x2F;&#x2F;eprint.iacr.org&#x2F;2017&#x2F;985" rel="nofollow">https:&#x2F;&#x2F;eprint.iacr.org&#x2F;2017&#x2F;985</a><p>[2] <a href="https:&#x2F;&#x2F;cs.nyu.edu&#x2F;~dodis&#x2F;ps&#x2F;merkle.pdf" rel="nofollow">https:&#x2F;&#x2F;cs.nyu.edu&#x2F;~dodis&#x2F;ps&#x2F;merkle.pdf</a>