The spec currently says: "XEdDSA and VXEdDSA require a cryptographic hash function. The default hash function is SHA-512 [10]."
"Default" sounds a little like "SHA-512 is nice but you can use another function in your private implementation" -- and people sometimes make use of such choices for whatever reason, which is bad enough. If additionally the structure of the input is optimized for SHA-512, then I think it makes sense to make SHA-512 a hard requirement. (Sure, we want to replace the hash function if it fails but then it's necessary to update the spec anyway.) Tim On Sat, 2016-10-29 at 18:47 -0400, Trevor Perrin wrote: > On Fri, Oct 28, 2016 at 12:47 PM, Trevor Perrin <tr...@trevp.net> > wrote: > > On Fri, Oct 28, 2016 at 2:40 AM, Brian Smith <br...@briansmith.org> > > wrote: > > [...] > > > Consider this "best of both worlds" scheme: > > > > > > r = hash1(a || [first half of Z] || M || [second half of Z]) > > Samuel Neves mentioned (off-list) that with SHA512's 128-byte block > size, a and M would still be mingled together in the first block. > > So I'm thinking about this: > > a || Z || pad || M > > where "pad" adds zero bytes to fill the hash block (so 32 bytes with > 25519 and SHA512, since |a|=32 and |Z|=64). > > Rationale: > (1) In the Random Oracle Model, this is no different from hashing "a > > > M || Z". > > (2) Processing the secret inputs (a and Z) in a separate block (or > blocks) from M seems cleaner > (3) Mixing the secret key with secret random data (Z) prior to > mixing > it with known input (M) is better for resisting physical sidechannels > (power, EM). > (4) The prior rationale for hashing Z at the end was weak: It might > help protect a very weak hash where the attacker was able to choose M > to force biases or collisions, even with unknown and randomized > prefix. But I think the sidechannel threat is more plausible. > - We could consider a || Z1 || pad || M || Z2, but the risk of (4) > is > low enough that I doubt that's worth the complexity > > Thoughts? > > Trevor > _______________________________________________ > Curves mailing list > Curves@moderncrypto.org > https://moderncrypto.org/mailman/listinfo/curves _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves