Re: [Cfrg] Help with the use of contexts

I agree with Dan Bernstein's suggestion and reasoning below against CFRG's currently contextualization of signature schemes, though I would also understand if CFRG does not want to reverse its decisions.

Further points:

Protocol designers should be responsible to enforce uniqueness of protocol messages (within and between honest protocols), not just for digital signatures but for all forms of authentication.  How much is this to ask? Isn't that kind of reliability their bread-and-butter?  If there hadn't been non-uniqueness, then cross-protocol attacks would have failed, right?

Adding a context to signatures is a complexity that is (1) not guaranteed to help (no formal security definition, no security proof? And no, I do not volunteer), (2) potentially collides with non-contextualized signatures (must signers now also track whether each non-context signature corresponds to some contextual signature?), (3) blames crypto for too much ;)

-----Original Message-----
From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of D. J. Bernstein
Sent: Monday, January 16, 2017 3:10 PM
To: cfrg@irtf.org
Subject: Re: [Cfrg] Help with the use of contexts

Adam Langley writes:
> The way that this is constructed (due to me) is generic for any 
> signature scheme. (Basically just have the context string be 
> NUL-terminated at the beginning of the signed message.)

In other words, there's still a simple sign-a-message layer that uses the standard signature API, that works with all signature systems, and that minimizes costs for implementors and auditors. On top of this there's a universal

   def sign_a_context_and_data(c,d):
     if '\0' in c: raise Exception('NUL not allowed in contexts')
     return sign(c + '\0' + d)

layer used by the protocol (and by any other protocols that want it).
Everyone can see how this works from a spec perspective and from a software-engineering perspective.

For comparison, trying to modify the interface and specification of every sign() function creates a transition nightmare, with nobody able to answer basic questions about how this approach is actually supposed to work. What's the advantage supposed to be?

I would really like to see this unnecessary complexity eliminated from CFRG's signature specifications. Please see

   https://www.ietf.org/mail-archive/web/cfrg/current/msg08167.html

for further comments.

---Dan

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg