Re: [Cfrg] Big-key cryptography

Dan Brown <dbrown@certicom.com> Mon, 07 December 2015 00:58 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B8F1A9058 for <cfrg@ietfa.amsl.com>; Sun, 6 Dec 2015 16:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 U_unfBRxqhG4 for <cfrg@ietfa.amsl.com>; Sun, 6 Dec 2015 16:58:01 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id AE3611A9057 for <cfrg@irtf.org>; Sun, 6 Dec 2015 16:58:01 -0800 (PST)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/AES256-SHA; 06 Dec 2015 20:09:30 -0500
Received: from XCT116CNC.rim.net (10.65.161.216) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Sun, 6 Dec 2015 19:57:54 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Sun, 6 Dec 2015 19:57:54 -0500
From: Dan Brown <dbrown@certicom.com>
To: Aaron Zauner <azet@azet.org>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Big-key cryptography
Thread-Index: AQHRMIYmUHlmDLkAAEiU6TTURCnWCp6+s49P
Date: Mon, 07 Dec 2015 00:57:53 +0000
Message-ID: <20151207005751.5701716.77110.10391@certicom.com>
References: <5664D280.306@azet.org>
In-Reply-To: <5664D280.306@azet.org>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/RnMmqxd9TXsXENjnAlX0mN8-nQA>
Subject: Re: [Cfrg] Big-key cryptography
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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: Mon, 07 Dec 2015 00:58:03 -0000

it looks interesting, but am so far having trouble with the threat model and actual proposal, though maybe others understood better than I did:

how realistic is this exfiltration adversary that the scheme aims to protect against? eg why not exfiltrate an inbox instead? if R is published, why not exfiltrate the p bits needed?

is there a bigkey per each pair of users, and how is it established? with small-key public keys?


  Original Message
From: Aaron Zauner
Sent: Sunday, December 6, 2015 7:28 PM
To: 'cfrg@irtf.org'
Subject: [Cfrg] Big-key cryptography


Hi,

People that have read Rogaway's recent IACR Distinguished Lecture [0]
might have noticed (besides an amazing essay on crypto, ethics and
politics of course) that there's new work mentioned on something they
call 'Big-key cryptography'. Let me quote Verbatim:

```
Suppose you have a bigkey K. You want to use it for some protocol P that
has been designed to use a conventional-length key K. So choose a random
value R (maybe 256 bits) and hash it to get some number p of probes into
the bigkey:

i_1 = H(R, 1) i_2 = H(R, 2) ... i_p = H(R, p) .

Each probe i_j points into K: it’s a number between 1 and |K|. So you
grab the p bits at those locations and hash them, along with R, to get a
derived key K:

K = H'(R, K[i_1], . . . , K[i_p]) = XKEY(K, R) .

Where you would otherwise have used the protocol P with a shared key K,
you will now use P with a shared bigkey K, a freshly chosen R, this
determining the conventional key K = XKEY(K, R).

We show that derived-key K is indistinguishable from a uniformly random
key K0 even if the adversary gets R and can learn lots of information
about the bigkey K. The result is quantitative, measuring how good the
derived key is as a function of the length of the bigkey, the number of
bits leaked from it, the number of probes p, the length of R, and the
number of random-oracle calls.

[...]

I think that the subkey prediction problem, and the key-encapsulation
algorithm based on it, will give rise to nice means for
exfiltration-resistant authenticated-encryption and pseudorandom
generators. In general, I see bigkey cryptography as one tool that
cryptographers can contribute to make mass surveillance harder.
```

This seems to be a yet unpublished manuscript but I can think of quite a
few instances where this approach might come in handy for keys used in
various high-confidentiality protocols. What does CFRG think?

Thanks,
Aaron

[0] - http://web.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf p. 31-32