This recent paper demonstrates using a differential power analysis attack on the SHA-512 part of the Ed25519 signature generation to recover the nonce key (aka auxiliary key), and also proposes a mitigation: https://eprint.iacr.org/2017/985.pdf
We need to create a scenario such that an attacker is not able
make a hypothesis on the constant key value. 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. The
input message will be processed in blocks after that. Fig. 9 visualizes how the
input should look. The R0 block would be a random number of 768 bits. We
argue that is also possible to have an R0 block composed by 128 bits of randomness
and pad the rest of the block with 640 bits with a constant value (e.g. all
zero).
[...]
Obviously, this countermeasure kills the deterministic signature properties,
but we do not see this as a dramatic problem. The main motivation for the proposal
of deterministic signature was to avoid a poor management of randomness
that can introduce security problems [12, 14]. The proposed countermeasure is
also not re-introducing the strong security requirement of randomness needed
by ECDSA. Basically, even if the same randomness is used to sign two different
messages, the attacker will not be able to recover the key as would it be possible
with ECDSA. Additionally we want to highlight that the signature verification
procedure remains as is.
As I'm using Ed25519 in an IoT-type device where this type of attack is (at least theoretically) possible, I'm considering adding (optional) support for this mitigation. Would there be interest in this if I provide a PR?
It should be straightforward to add this logic to EdDSAEngine.digestInitSign, conditional on a (new) randomize flag added to EdDSAParameterSpec, which could then be exposed as an EdDSANamedCurveSpec with a different identifier, e.g. Ed25519rnd.
This recent paper demonstrates using a differential power analysis attack on the SHA-512 part of the Ed25519 signature generation to recover the nonce key (aka auxiliary key), and also proposes a mitigation: https://eprint.iacr.org/2017/985.pdf
As I'm using Ed25519 in an IoT-type device where this type of attack is (at least theoretically) possible, I'm considering adding (optional) support for this mitigation. Would there be interest in this if I provide a PR?
It should be straightforward to add this logic to
EdDSAEngine.digestInitSign, conditional on a (new)randomizeflag added toEdDSAParameterSpec, which could then be exposed as anEdDSANamedCurveSpecwith a different identifier, e.g.Ed25519rnd.