[curves] Ed25519 / EdDSA key leakage due to fragility in recommended nonce procedure

[steve at tobtu.com]

I don't know how many people got Ben Harris's email because it bounced due to DMARC https://support.google.com/mail/answer/2451690. Anyway if you didn't get it then it's below.

> On January 30, 2020 at 8:42 PM Ben Harris <mail at bharr.is> wrote:
> 
> 
> On Thu, 30 Jan 2020 at 21:16, Conrado P. L. Gouvêa <conradoplg at gmail.com>
> wrote:
> 
> > I'm very interested in that! I also wonder about Ed448 / Ed25519ph /
> > Ed25519ctx which have some constant inputs when generating the nonce.
> > Does that interfere when trying to protect against DPA attacks? (I've
> > asked about this in
> >
> > https://crypto.stackexchange.com/questions/77260/protecting-ed448-against-dpa-and-fault-attacks
> > , maybe I should ask here?)
> >
> 
> 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.
> 
> Presumably you'd change RFC8032 5.2.6. something like this:
> 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.
> 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.
> _______________________________________________
> Curves mailing list
> Curves at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/curves