Re: [Cfrg] Help with the use of contexts

[Natanael <[e-mail]>]

Den 3 feb. 2017 13:55 skrev "Ilari Liusvaara" <[e-mail]>:

On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
> On 30 January 2017 at 12:40, Paterson, Kenny <[e-mail]>
> wrote:

> > So: does anyone else want to offer an opinion on the question of
contexts?
> >
> Contexts are a clean and relatively simple way to prevent cross-protocol
> attacks, in particular when implemented in an as simple way as proposed
> by Adam and Dan.

Unfortunately, in practice those are anything but clean and simple.

Yes, the theoretical notion is pretty simple (where (context,message)
tuple replaces the message in standard notion of signature security).

The biggest practical problem: Backwards compatiblity, the ever-present
nemsis of security.

There are basically two major problems:

- Non-contextualized schemes, which leave the system wide open for
  any possible attacks. Hopefully nothing major.
- The standard signature API can't accomodiate contexts.


Couldn't we go the other way and suggest that people don't simply use the
raw signature primitive, and instead only use a message format that
includes room for contexts? Because in general, only cryptographers should
deal with the raw primitives.

Can anybody find a flaw with the following?

Sign(<private key>;
    SHAKE256(<output length parameter>;
        <[hexadecimal encoded output length in bits],
        [Base64(Signature algorithm + format identifier],
        [Base64(Context identifier)],
        [hexadecimal encoded message hash]>))

= message signature, context

You feed in the message, key and context, the rest is hardcoded in the
context aware software.

Question: should the public key be included among the above inputs?
Depending on the signature scheme it may not always be formatted as
expected by the verifier (malleability, etc), and must thus be forwarded
along with every message.
This could perhaps be algorithm specific, since those algorithms with a
deterministic public key encoding can hash it without publishing it with
the message, and still validate.

The signature algorithm description could use predefined ciphersuite
identifiers (much like TLS does), defining the exact choices in use.

The above SHAKE256 inputs should also be encoded with prefixes like a null
byte to guarantee there can be no manufactured collision spanning across
them.



This should in theory provide a context-equipped signature that will not
collide accidentally with context-less messages, and will not collide
across unique signature algorithms/formats, and in particular will not
collide across contexts.

It should also resist most imaginable attacks including length extension
attacks and similar, while also naturally being able to generate arbitary
length hashes (SHAKE256) for the signing primitives (which may use unusual
input lengths). It even achieves this without truncation or padding!
Another question, should we prefix the SHAKE256 output? Is there any
attacks that would stop?

This format should also stop context-unaware software (which can be
presumed to be intended to NOT be able to parse these message) from being
able to validate these signatures, preventing these signatures from
enabling cross-protocol attacks elsewhere.
While one could verify the signature of the raw SHAKE256 output, it would
be meaningless to most unaware software.

Software only expecting signatures with contexts also wouldn't accept
context-less signatures, as they would be extremely unlikely to validate
(assuming SHAKE256 is secure).
The exception is if a context-less program would be insecure and behave as
a signature oracle or even be malicious and thus could be manipulated to
generate such a SHAKE256 output to be signed, to be used against context
aware software.

(Sorry if anything is incoherent, my phone keyboard app Swiftkey bugged out
and started deleting text. Had to rewrite a lot.)