[curves] XEdDSA specification

[Brian Smith]

Trevor Perrin <trevp at trevp.net> 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).
>

This also makes sense to me, and also partially addresses my question about
whether |Z| should be a function of the block size of the hash function.


>  (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
>

I would like to read more about attacks of the form of #4, if people have
references. Up to now I've always lived a life of luxury wherein I have
been allowed to assume there is no such attack, but I've not searched hard
for research on that matter either.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20161029/159a52b7/attachment.html>