<div dir="ltr"><div dir="ltr">On Thu, 30 Jan 2020 at 21:16, Conrado P. L. Gouvêa <<a href="mailto:conradoplg@gmail.com">conradoplg@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm very interested in that! I also wonder about Ed448 / Ed25519ph /<br>
Ed25519ctx which have some constant inputs when generating the nonce.<br>
Does that interfere when trying to protect against DPA attacks? (I've<br>
asked about this in<br>
<a href="https://crypto.stackexchange.com/questions/77260/protecting-ed448-against-dpa-and-fault-attacks" rel="noreferrer" target="_blank">https://crypto.stackexchange.com/questions/77260/protecting-ed448-against-dpa-and-fault-attacks</a><br>
, maybe I should ask here?)<br></blockquote><div><br></div><div>It appears from a quick scan that power attacks on SHAKE are mostly circumvented (for the theta transform anyway) by using at least 80 bytes of 'unknown' in the transform to prevent correlation through the XORs.</div><div><br></div><div>Presumably you'd change RFC8032 5.2.6. something like this:</div><div>1) Call SHAKE256(x, 137) instead of SHAKE256(x, 114) - s is still 57 bytes, prefix is now 80 bytes. The length doesn't appear to be an input to the digest (only a truncation) so this change doesn't alter s or the public key.</div><div>2) Get r using SHAKE256(prefix || dom4(F, C) || A || PH(M), 114) instead of SHAKE256(dom4(F, C) || prefix || PH(M), 114). dom4 is variable length so having it first might make prefix behave as two 40 bytes (e.g. LEN(C)=86) which is breakable through power analysis. Adding 'A' in there makes this a little more foolproof as discussed in this thread.</div><div><br></div><div><br></div><div><br></div></div></div>