Discussion on power analysis attacks

[sipa]

See https://eprint.iacr.org/2017/985.pdf, which describes an attack against Ed25519, by doing power analysis on the nonce generation function.

It relies on having a single SHA512 message block that contains both attacker-controlled data, and secret data that the attacker wishes to learn. We use SHA256 instead of SHA512, but it is sufficiently similar that we should perhaps at least consider if the same kind of attack could apply.

With #194, our nonce generation function would effectively become H(priv || pub || msg [|| randomness]). All the secret data goes into the first compression, and all attacker-controlled data goes into the second compression, so I think the attack does not apply directly already, but maybe related attacks do. I'll email the authors of the paper about this.

The paper however suggests having at least 128 bits of randomness (synthetic nonce!) in the first hash block. I wonder if that means we should move the randomness to after the priv, so H(priv || randomness || pub || msg). That means that if the randomness has at least 128 bits of entropy, we've effectively implemented their countermeasure, but at the cost of losing the ability to precompute the midstate at H(priv || pubkey || ...).

Anyone have any thoughts?

[gmaxwell]

H(priv || pub || pad to block (if pub isn't 32 bytes) || random || pad to block || message) is superior, as it increases the precomputable data, and still implements their counter measure I think (which works by having there be a compression with attacker unknown random data before any with attacker controlled inputs).

[sipa]

if pub isn't 32 bytes

It is, making the first padding unnecessary (we don't need to commit to the negation flag if we use the private key post-negation).

random || pad to block

That would increase the number of compression function invocations. I'm not sure it adds anything?

[gmaxwell]

My reasoning was that there should be no attacker controlled data in a compression function run where the midstate is a constant secret.

[ajtowns]

My reasoning was that there should be no attacker controlled data in a compression function run where the midstate is a constant secret.

Rather than having a cached midstate and two compression functions, you could do H(rand23 || sk || pk || m) which would satisfy that requirement with two compression functions but not needing cached midstate?

[real-or-random]

Rather than having a cached midstate and two compression functions, you could do H(rand23 || sk || pk || m) which would satisfy that requirement with two compression functions but not needing cached midstate?

I like that idea.

And in general, implementing this protection seems to be a good idea. In the end it's never clear how effective these countermeasures are but this one here seem to make the attack at least harder and it does not introduce any drawbacks.

[gmaxwell]

Well the drawback is two compression function runs at runtime instead of one... but high speed implementations can implement alternative schemes.

Also the drawback is that you can't use comparison to check what nonce implementation a black box is using if synthetic nonces are in use... but it seems in practice no one actually does this anyways (or even cares when that test returns a failure-- something claims outright to be 6979 but its results are not reproducible).

[jonasnick]

H(priv || pub || msg || randomness]). All the secret data goes into the first compression, and all attacker-controlled data goes into the second compression, so I think the attack does not apply directly already, but maybe related attacks do.

Seems more likely than not that such attacks exist. At least it's easy to imagine an otherwise hash function that is vulnerable.

In "Differential power analysis of HMAC based on SHA-2, and countermeasures" (google), McEvoy et al. stipulate an DPA attack that recovers the midstate of SHA256(x || m) where x is the secret key padded to the blocksize.

Their countermeasure is using a hash function similar to SHA256 but where individual operations are masked. Perhaps they don't simply pad the secret key with randomness because they don't want to make assumptions about the length of the secret key and how much space is available for padding (EDIT: the more likely reason is that they want to compatible with HMAC-SHA-2, so they mask the input and unmask the output of HMAC). I have not read the paper in detail (nor do I have much experience with DPA) but it seems that the H(rand23 || sk || pk || m) would equally thwart their attack:

the hash function is operating on (k ⊕ ipad), [k is the secret key and padded to the blocksize] which clearly
does not change from one execution of the HMAC algorithm to the next. Hence,
the intermediate hash H_1 is also fixed and unknown. Recall that in order to
perform a differential side-channel attack, we require fixed unknown data to
be combined with variable known data. This criterion is fulfilled during the
calculation of H_2 , when the variable m is introduced and combined with the
previous intermediate hash H_1

[jonasnick]

This synthetic nonce idea added to the WIP reference code update PR: f84cd77

[sipa]

@jonasnick That's a great find.

So I think the general principles are that you should never have (unmasked) secret data together with attacker-controlled data within one input block (because expansion is independent of midstate) or when updating a midstate in a compression step.

That means the following things are insecure (assuming 16 byte rand).

• H(priv||pub||rand||msg) (combining a secret midstate with an attacker-controlled msg).
• H(rand||priv||pub||msg) (the second block contains both private and attacker-controlled data).

These however seem fine (each is listed with: total compressions; compression with precomputed key; compressions with precomputed key+rand):

• H(priv||rand||pub||msg): 2, 2, 1
• H(rand||priv||pub||msg): 2, 2, 1 (but unsafe with 33 <= len(rand) <= 63).
• H(priv||pub||rand||pad_to_block||msg): 3, 2, 1
• H(rand||pad_to_block||priv||pub||msg): 3, 3, 1

So moving the randomness to the second block to enable precomputating H(priv||pub means we need to add padding, which effectively undoes the gains of precomputation.

My preference is thus H(priv||rand||pub||msg). This never needs any padding, and seems safe for any length of rand >= 16. If we want to treat msg as variable-length too (not supported by BIP340, but who knows maybe someone builds a variant), rand should probably be prefixed with a 1-byte length.

[jonasnick]

H(rand||privkey||pubkey||msg) (the second block contains both private and attacker-controlled data).

Doesn't the second block consist of <last 16 bytes of pubkey><msg><padding> ?

[sipa]

Oh, you're right. Adding that one:

• H(rand||priv||pub||msg): 2, 2, 1. Just as good as H(priv||rand||pub||msg).

[sipa]

H(rand||priv||pub||msg) is however a problem when 33 <= len(rand) <= 63 (which is pointlessly large, so not recommended in any case).

[sipa]

Perhaps this isn't worth spending too much time on. Adding randomness to protect against power analysis can only protect the signature, but systems where attacks like this are a risk will likely also performing BIP32 derivation and Taproot tweaking, where randomness cannot help.

Adding randomness remains useful as a countermeasure against fault attacks though, but the element ordering does not matter for that.