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

[Ilari Liusvaara <[e-mail]>]

On Mon, Mar 25, 2024 at 02:52:57PM -0000, D. J. Bernstein wrote:
> Ilari Liusvaara writes:
> > The end result of only having message signatures would be hybrid
> > signatures not getting deployed at all, or protocol designers coming
> > up with their own ways, completely incompatible and with all sorts of
> > exciting problems.
> 
> Please clarify. What does "only having message signatures" mean here? Is
> this supposed to be a property that isn't achieved by the signed
> messages "(s2,s1,r,h,m)" from my previous email?

"only having message signatures" means not having the raw message (m) in
the tuple. If one has m in the tuple, it is trivial to split it out for
detached signatures.

 
> Signed-message APIs reduce errors. Consequently, it's good for a
> combiner to be designed so that a signed-message API for the combiner is
> easy to build from such APIs for the internal signature schemes. This is
> compatible with the same combiner _also_ allowing a detached-signature
> API, such as sending (s2,s1,r,h) detached from the original message m.

Reduce errors, yes. Unfortunately most stuff has been designed in a way
that requires detached-signature API.

Another API consideration: That (s2,s1,r,h) needs to be packed as a byte
string. Not doing so would cause a lot of completely unnecessary
complexity. A fairly minor example can be seen with ECDSA: Some stuff
uses whatever that ASN.1 based signature format is (blech) and others
use the simpler concatenated format.

(And I would worry less if there was no feasible way to come up with any
(message, signature) pairs valid under the component keys from the
hybrid signature. However, no generic combiner can have this property
(there is a trivial attack), but I do not see any theoretical blocker
for non-generic hybrids.)




-Ilari