Re: [Cfrg] Side inputs to signature systems

[Natanael <[e-mail]>]

Den 1 sep 2015 17:51 skrev "D. J. Bernstein" <[e-mail]>:
>
> Simon Josefsson writes:
> > Do you have a concrete example?  I would consider that a protocol flaw.
>
> It's certainly a protocol flaw---but sometimes designers of multiple
> protocols, or multiple protocol components, don't talk to each other:

[...]

> The standard fix for this type of problem is to encode more information
> into the signed messages so that they can't be taken out of context. Of
> course, to figure out how much information is enough, you have to work
> at the protocol layer, understanding all the different contexts in all
> of the high-level protocols that might sign messages under the same
> key---and the protocol designers need to talk to each other! Any
> encoding, no matter how verbose, can be ruined by another protocol
> assigning new meanings to some of the encoded messages.

[...]

>    * What exactly are the format and semantics of this input? For
>      example, how exactly would this side input be used to stop the TLS
>      bug mentioned above?

I've got one suggestion. It may be impractical to implement or maybe even
impossible in some circumstances, but I believe it would work when designed
for from the start;

Every signature in every context needs a unique deterministic nonce.

The nonce is derived from at least the following: the signing public key,
the message *and the code path of invocation* (as how the spec defines
it!), and probably a standard cryptographic nonce/counter.

A signature to be generated by signing function X which was called by
function A takes a unique constant from A and from X and hash them together
with the above mentioned data, pre-sorted in a specific way. Let's say we
have a revocation signature feature and a command message signing feature -
the feature who's function calls the signing function has its own constant
come first before hashing to create the nonce. The hashing function may be
a MAC, or some other function resistant to extension attacks.

If some implementation does things internally in a non-standard order it
must track the official order of doing things, as well as be careful to not
itself create ambiguity. The nonce creation behavior should be replicated
exactly.

I don't personally care how this context nonce is included. It might be
easier to just sign it with the rest of the message.