Re: [CFRG] How to construct a hybrid signature combiner?

[Simon Josefsson <[e-mail]>]

"D. J. Bernstein" <[e-mail]> writes:

> A combiner proposal that combines (ahem) all of the above is for a
> signed message to be (s2,s1,r,h,m) where
>
>    m = the message being signed,
>    r = H(fresh randomness chosen during signing),
>    h = H(r,H(hybridpk),hybridsigname,appname,appcontext,m),
>    s1 = Ed25519 signature of (r,h),
>    s2 = post-quantum signature of (s1,r,h),
>    H = SHA3-256.

Thanks, this was exactly what I was hoping to see -- this looks
reasonable easy to describe and implement, assuming its security holds
if Ed25519 is replaced with RSA or ECDSA?  And doesn't require anything
from not normally assumed from the post-quantum signature scheme.  Now
all we need is a name...

Ilari Liusvaara <[e-mail]> writes:

>> One more recommendation is to include the signature-system name and
>> application name as extra hash inputs (along with any context specified
>> by the application), in a way that can be uniquely parsed across
>> applications, so that signatures can't be moved across protocols.
>
> That has been tried. Turned out to be a major mistake.

There are good arguments on both sides here -- however what I haven't
seen proposed is a compromise solution: allow protocols to provide a
context name but have the signature combiner provide a default one if
the application protocol doesn't supply it.  This solves the API problem
of libraries/applications not knowing what to put in that field when it
is not specified, but still offers domain-separation for the situations
that care about it.  Would this address these concerns?  What other
disadvantages have we learned about context strings?

/Simon