Re: [Cfrg] Help with the use of contexts

Natanael <natanael.l@gmail.com> Fri, 03 February 2017 14:41 UTC

Return-Path: <natanael.l@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ACB129D9D for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 06:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygVaaGhp-gxY for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 06:41:39 -0800 (PST)
Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0B2129D9B for <cfrg@irtf.org>; Fri, 3 Feb 2017 06:41:39 -0800 (PST)
Received: by mail-yb0-x242.google.com with SMTP id w194so872767ybe.1 for <cfrg@irtf.org>; Fri, 03 Feb 2017 06:41:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=682bxI7RpYAiCNYu62huJLhJ6J8yyK80hWj0x5xQxNU=; b=BmPgByPQpHxv7HgL7/nr53ZlyDA3z828xbrXLCyHE79svnKht3ztMAJHoRYT+eN9lb 4kcmBP/0Y2Klx4N+pQq57b4Q9SNxoJNmbqXjb/HUO3VUj9u5kkROkztqFuYB4BsHG/h6 hxAALf9gQktLDjOJelrlr5PdTHPHwP9pnJ12fXvZ7zT2+zfI7eb1p3G5w7EDQpCou4q5 8h/Y29BfIbnpkqIFfYwO94Oe4fBykUCxIgL0kNOhm8wY28B5B0pBDFdPGtKA9XvBJdRf bnhLnT5u7O7zbDkyj17Af3lPyw5KXNaIUUQQHXpPUMVSvY/aoVYVYu0aE4keBIGg916W UIFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=682bxI7RpYAiCNYu62huJLhJ6J8yyK80hWj0x5xQxNU=; b=DRG7G6KCHEXx84QLvu18n/f7pvPhyfRp1Lq4aGFhi2MVSgrd5bHz+8xrlVElrWj9rq h05uK4H3um7aC3EDuztKxfBQ3gsdb+qTxp9IYRWPlJWu7o9lsy76Cji6erT5k0FFJrf5 7SmrG2k0cT2LzP6+shDiCSuZPKVVIYWeyIGRkdSdVq9h075FK2+UzQXjWUfyj4w/m8BB 7UvemSbfrrHBq7xwukSb5/Q/xUcWn2cQY68+TZM7DfJ5izMsxTdcFg/o4WanE/cRCVCa J4bKLK2R3Br5LbLze91Sqdh9uHbmGPRJ1qwt6X+lYtwGkfXMmYTmhIDi64Da9sg8sidR CKsA==
X-Gm-Message-State: AIkVDXLqZeGc/aYPguexHEu5V5gFSLSu+X7dTHCbxSBbJIW+SEfNeRLhByPj3Jn5iWyp0QVPrrXeNFNiAoscIg==
X-Received: by 10.37.31.85 with SMTP id f82mr5802923ybf.188.1486132898548; Fri, 03 Feb 2017 06:41:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.75.67 with HTTP; Fri, 3 Feb 2017 06:41:37 -0800 (PST)
Received: by 10.37.75.67 with HTTP; Fri, 3 Feb 2017 06:41:37 -0800 (PST)
In-Reply-To: <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20170116200948.6535.qmail@cr.yp.to> <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie> <AA42E783-43FC-4C9B-A387-623B5B18B4FB@gmail.com> <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com> <CACsn0cm22h8_61CEZjKYyHfnd7vvnC39ZMjhusjWcZKu_Z0zhw@mail.gmail.com> <DA141A39-05C2-4B87-92FA-AE8C5421E104@gmail.com> <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie> <D4B4D5E4.82A6D%kenny.paterson@rhul.ac.uk> <CA+yVaTxTbqDUBbX2oTgC6BT2LprOz8uqAbhTRukuqfZD124kSA@mail.gmail.com> <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi>
From: Natanael <natanael.l@gmail.com>
Date: Fri, 3 Feb 2017 15:41:37 +0100
Message-ID: <CAAt2M18=P3WyA-NBZ9S8VS9Q7LsVyOu39+bGFKZbVP5k5AjsKg@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=001a1143e93281d3bb0547a147e7
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/FrwVWC7n7qeNUFZwvSQz3f8af1E>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Help with the use of contexts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 14:41:41 -0000

Den 3 feb. 2017 13:55 skrev "Ilari Liusvaara" <ilariliusvaara@welho.com>om>:

On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
> On 30 January 2017 at 12:40, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
> 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.)