Re: [Cfrg] Side inputs to signature systems, take 2

[Natanael <[e-mail]>]

Den 23 apr. 2016 15:00 skrev "D. J. Bernstein" <[e-mail]>:
>
> Here's the standard API for signature systems:
>
>    * keygen inputs: nothing; outputs: public key, secret key;
>    * sign inputs: message (string), secret key; outputs: signature;
>    * verification inputs: message, signature, public key: outputs: yes/no.
>
> This API is overwhelmingly popular in the cryptographic literature, the
> security literature, and the software ecosystem. It is shared by the
> vast majority of
>
>    * specifications of signature systems,
>    * papers analyzing the security of signature systems,
>    * theoretical proofs regarding signature systems,
>    * cryptographic libraries, and
>    * applications of signatures at higher layers of software.
>
> This sharing is tremendously helpful---compare it to all the horror
> stories of mismatched APIs slowing everybody down, making the auditor's
> job hellishly difficult, and producing real-world security problems. The
> simple fact that the signature API is so popular means that any change
> to the API comes with a heavy presumption of being a _very bad idea_.
>
> I'm not saying that it's impossible to rebut this presumption. For
> example, I recommend merging the message and signature into a signed
> message---I'm acutely aware of how many system layers need to be adapted
> to make this work, but I don't see any other plausible way to eliminate
> the very common "use the message without noticing it's a forgery" error
> pattern. Stateful signatures are a deeper example. In both of these
> cases I see clear, convincing reasons for a new API, outweighing the
> massive costs and dangers---but changing the API is obviously an uphill
> battle against a default position of amply justified skepticism.

> Encoding the same information into traditional messages does just as
> well in stopping cross-protocol attacks as a "context" side input can
> possibly do. The API divergence is unnecessary and highly undesirable.

I'm just going to add a few more comments in addition to my reply from the
last time.

(And as always, anything of this complexity is unlikely to ever get
implemented, or implemented right for that matter. This is mostly a thought
experiment.)

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

Summary of how to define the context:

Track the path / branch taken through the code in the generation of the
signed message (identifying the software, the configuration / instance of
it, what it was that invoked the generation of the signature, which checks
the software went through to confirm it should be created, or whatever else
is important). Encode that with the message.

Document what each section of each code branch means, which paths are
valid, what exactly is authorized by any given path's signatures.

A code path that only covers acknowledgement of receipt obviously can't be
use to issue orders of action. Anything that parse the signed messages for
some given system must follow the documentation and must be able to
determine what exact actions a message authorizes. Ideally every type of
valid action should also be explicitly defined in the documentation, so
that this is possible to begin with.

The more I think of it, the more it resembles building a capabilities
oriented system. A bit like an adaption of Bitcoin pay-to-script-hash
transactions / Ethereum, where the system declares what conditions must be
fulfilled for every given action, and where the signed messages
(transactions) must prove the conditions were fulfilled. Take a look at
Bitcoin's Merkelized Abstract Syntax Trees (MAST) for a highly relevant
reference.
http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik-nityas.pdf

You shouldn't sign messages with this data structure without first
verifying it does what you want (to not fall for signature oracle attacks).
If everybody follows that advice, you can be sure that the signer intended
to create that particular message.

---

By my reading, it sounds like you'd rather see something like a specific
signature message input format, where you sign some structured data that
encode the message. (Perhaps we could use the new saltpack format, and
define some json / xml data structure for encoding contexts, etc.)

As for the comment on preventing (carelessly) stripping out the raw message
without further verification: encrypt the message with a key derived from
the metadata (the non-message parts of the data structure) and signature.
Yes, this too is likely to be bypassed by careless programmers, but at
least they should have come across an warnings against doing so when
reading the documentation on how to extract the message. It shouldn't end
up like this:
https://xkcd.com/1181/