Subject: [Cfrg] Signature contexts -> Re: testability of signature input/output parameters

From: Paul Lambert <[email-masked]>
Date: Fri, 5 Jun 2015 16:46:27 +0000

>
>
>
>
>4) Signature contexts
>
>Extra data that must match between signer and verifier, to counter cross-
>protocol attacks.
>
>Cross-protocol attacks against signatures seem to be dime dozen.

Interesting problem area, however Š

This seems like something that more generally should be part of the
semantics of the signed information rather than overloading the
cryptographic signature.

If you're proposing a form of signature that would only be able to be
validated by a specific target verifier (public key owner) then the
overall use case and flow become very different from what I assume we mean
by ¹signature¹.   

Paul

>
>
>-Ilari
>
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Natanael <[email-masked]>
Date: Fri, 5 Jun 2015 19:29:07 +0200

> overall use case and flow become very different from what I assume we mean

How about defining a field that can be used to specify protocol usage /
context, which is signed together with the plaintext? Similar to the common
version number headers in PGP ASCII armored blocks, it can be ignored by
implementations that don't care about it, but allows for the
implementations who care about it to flag what should be used where and
reject signed data with the wrong context.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 5 Jun 2015 20:32:40 +0300

> semantics of the signed information rather than overloading the

The problem that two protocols will probably conflict about meaning of
at least some message, unless specifically designed not to.

Basically, if there are N contexts, there are N^2-N possible conflicts,
so it is not surprising those pop up (or worse, not pop up).

> overall use case and flow become very different from what I assume we mean

The contexts are intended to be fixed by protocol, and thus publically
known.

-Ilari

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 05 Jun 2015 15:36:44 -0400

On Fri 2015-06-05 13:29:07 -0400, Natanael wrote:
> How about defining a field that can be used to specify protocol usage
> / context, which is signed together with the plaintext? Similar to the
> common version number headers in PGP ASCII armored blocks, it can be
> ignored by implementations that don't care about it, but allows for
> the implementations who care about it to flag what should be used
> where and reject signed data with the wrong context.

fwiw, the "headers in PGP ASCII armored blocks" are not
cryptographically protected at all.  This is not a model to emulate :)

        --dkg

---

From: Paul Lambert <[email-masked]>
Date: Sat, 6 Jun 2015 09:00:10 +0000

>so it is not surprising those pop up (or worse, not pop up).

Ok, thank you for your patient explanation.  I see where this might help,
but it does imply that the context needs to be an explicit parameter of a
signature API. 

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 6 Jun 2015 14:58:16 +0300

> but it does imply that the context needs to be an explicit parameter of a

Yes, it is signing and verifying parameter, simlarly as message. In fact,
in my prototypes, internally it gets treated as part of the message to
sign with the underlying simpler primitive.

-Ilari