There are some papers (1, 2) describing fault attacks in EdDSA. One suggested countermeasure is to add randomness to the input of the first hash call, which outputs a scalar.
This paper describes a DPA attack against EdDSA, and suggests a similar countermeasure. However, the randomness must be placed in a specific place:
This can be achieved by padding
the key with fresh random bits such that the first 1024-bit block is composed
only by key and random value, without any bits known to the attacker.
Following their notation, that would mean changing $H(b,M)$ to $H(b,Z,M)$ where $Z$ is the random padding such that the length of $b || Z$ is equal to the block size of the hash.
However, consider Ed448, as defined in RFC 8032 (the issue I’ll talk about would also apply to Ed25519ctx and Ed25519ph, but I’ll use Ed448 as an example). In the Sign operation, the hash call is
SHAKE256(dom4(prehash, context) || b || PH(M), 114). Prehash is a flag indicating Ed448 or Ed448ph. Context is an optional context string. The
dom4 function is:
dom4(x, y): The octet string
"SigEd448" || octet(x) || octet(OLEN(y)) || y, where x is in range 0-255 and y is an octet string of at most 255 octets. “SigEd448” is in ASCII (8 octets).
Now, my question is: what is the proper way to add the DPA countermeasure to Ed448? (And Ed448ph, Ed25519ph, Ed25519ctx)?
My first guess would be to use
SHAKE256(dom4(prehash, context) || b || Z || PH(M), 114), with
Z being enough bytes to fill the SHAKE245 block size. However, if the context is used, then
Z could get too small. Also, the paper states that the first block must be “composed only by key and random value, without any bits known to the attacker”. Would the fixed bytes of the
dom4 function (“SigEd448” and so on) interfere with this? How to work around this?
Or maybe SHAKE256 is already DPA-resistant?
Get this bounty!!!