[curves] XEdDSA specification

[Tim Ruffing]

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 <trevp at trevp.net>
> wrote:
> > On Fri, Oct 28, 2016 at 2:40 AM, Brian Smith <brian at 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 at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/curves