Re: [Cfrg] Keys for multiple cryptographic uses (was: Re: Outline -> was Re: normative references)

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Thu, 16 January 2014 22:57 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 98E161ACCE6 for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 14:57:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.399
X-Spam-Level:
X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 ZcTEuKGYm_7o for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 14:57:27 -0800 (PST)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id D17CA1A1F65 for <cfrg@irtf.org>; Thu, 16 Jan 2014 14:57:26 -0800 (PST)
Received: from mail129-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE006.bigfish.com (10.174.14.69) with Microsoft SMTP Server id 14.1.225.22; Thu, 16 Jan 2014 22:57:14 +0000
Received: from mail129-db9 (localhost [127.0.0.1]) by mail129-db9-R.bigfish.com (Postfix) with ESMTP id 01DD23A00AC; Thu, 16 Jan 2014 22:57:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -8
X-BigFish: PS-8(z579ehzbb2dI98dI9371Ic89bh542I1432I4015I7f52hdbf2izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h17326ah8275bh8275dh1de097h186068h5eeeK1d68dehz2fh109h2a8h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h1155h)
Received-SPF: pass (mail129-db9: domain of rhul.ac.uk designates 157.56.249.149 as permitted sender) client-ip=157.56.249.149; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AM2PRD0311HT003.eurprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(779001)(679001)(689001)(243025003)(13464003)(51704005)(189002)(199002)(24454002)(377454003)(479174003)(164054003)(76796001)(76786001)(87266001)(93136001)(83322001)(19580405001)(92726001)(56816005)(87936001)(2656002)(74706001)(36756003)(69226001)(47446002)(19580395003)(81342001)(74662001)(47736001)(93516002)(74482001)(74502001)(49866001)(31966008)(47976001)(46102001)(15975445006)(54316002)(81542001)(80976001)(50986001)(79102001)(15202345003)(77982001)(51856001)(59766001)(66066001)(54356001)(92566001)(81686001)(325944007)(85852003)(85306002)(74876001)(56776001)(53806001)(74366001)(90146001)(83072002)(76482001)(4396001)(81816001)(65816001)(80022001)(83506001)(63696002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:38.121.228.3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail129-db9 (localhost.localdomain [127.0.0.1]) by mail129-db9 (MessageSwitch) id 1389913031377800_24266; Thu, 16 Jan 2014 22:57:11 +0000 (UTC)
Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.248]) by mail129-db9.bigfish.com (Postfix) with ESMTP id 55C5110004A; Thu, 16 Jan 2014 22:57:11 +0000 (UTC)
Received: from AM2PRD0311HT003.eurprd03.prod.outlook.com (157.56.249.149) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 16 Jan 2014 22:57:11 +0000
Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AM2PRD0311HT003.eurprd03.prod.outlook.com (10.255.162.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 16 Jan 2014 22:57:10 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.851.11; Thu, 16 Jan 2014 22:57:09 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0851.011; Thu, 16 Jan 2014 22:57:09 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Paul Lambert <paul@marvell.com>, Rene Struik <rstruik.ext@gmail.com>, David McGrew <mcgrew@cisco.com>, "Igoe, Kevin M." <kmigoe@nsa.gov>, Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [Cfrg] Keys for multiple cryptographic uses (was: Re: Outline -> was Re: normative references)
Thread-Index: AQHPEwq885T9nUz/l0CWc/t2sZEdFJqH8PuA//+xpoA=
Date: Thu, 16 Jan 2014 22:57:09 +0000
Message-ID: <CEFDCB1C.13EFA%kenny.paterson@rhul.ac.uk>
References: <CEFC6B5C.2C6E8%paul@marvell.com> <CACsn0ckSMUbEJ4F3bQ5KVMbhdPQw1MTMCce6B8uhMfA_V0Nupw@mail.gmail.com> <CEFCBB2E.2C792%paul@marvell.com> <3C4AAD4B5304AB44A6BA85173B4675CABA9A493F@MSMR-GH1-UEA03.corp.nsa.gov> <52D8417B.9030908@cisco.com> <52D85DBB.1010505@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7FB9E77@SC-VEXCH2.marvell.com>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7FB9E77@SC-VEXCH2.marvell.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [38.121.228.3]
x-forefront-prvs: 0093C80C01
Content-Type: text/plain; charset="utf-8"
Content-ID: <55F96AE1A8E6EF49AC5E6446B50C668B@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Keys for multiple cryptographic uses (was: Re: Outline -> was Re: normative references)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 22:57:29 -0000

Hi

There is significant *scientific* literature on the question of security
of multiple uses of keys - both for the setting where the same key is used
in more than one algorithm of the same type (under the name of
cryptographic agility) and where the same key is used in algorithms of
different types (e.g. same key in a signature scheme and in a public key
encryption scheme).

Cautionary examples include:

T. Jager, K.G. Paterson and J. Somorovsky, One Bad Apple: Backwards
Compatibility Attacks on State-of-the-Art Cryptography. In Network and
Distributed System Security Symposium (NDSS 2013).
http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf


J.P. Degabriele, A. Lehmann, K.G. Paterson, N.P. Smart and M. Strefler, On
the Joint Security of Encryption and Signature in EMV. In O. Dunkelmann
(ed.), CT-RSA 2012, Lecture Notes in Computer Science Vol. 7178, pp.
116-135, Springer, 2012. Full version at: http://eprint.iacr.org/2011/615


Positive (and some negative) results can be found in:

K.G. Paterson, J.C.N. Schuldt, M. Stam and S. Thomson, On the Joint
Security of Encryption and Signature, Revisited. In D.H. Lee and X. Wang
(eds.), ASIACRYPT 2011, Lecture Notes in Computer Science Vol. 7073, pp.
161-178, Springer, 2011. Full version at http://eprint.iacr.org/2011/486



Acar, T., Belenkiy, M., Bellare, M., Cash, D.: Cryptographic agility and
its relation to circular encryption.
In: Gilbert, H. (ed.) EUROCRYPT 2010. LNCS, vol. 6110, pp. 403{422.
Springer, Heidelberg (2010)

Coron, J.S., Joye, M., Naccache, D., Paillier, P.: Universal padding
schemes for RSA. In: Yung, M. (ed.)
CRYPTO 2002. LNCS, vol. 2442, pp. 226{241. Springer, Heidelberg (2002)

Haber, S., Pinkas, B.: Securely combining public-key cryptosystems. In:
ACM Conference on Computer and
Communications Security. pp. 215{224 (2001)





This list is by no means complete, but serves to illustrate that the
picture is complicated and we are far from having a full understanding of
this domain. Several additional references can be found in the
first-mentioned paper above.

Finally, let me draw your attention to this very recent paper which
highlights the issues arising from multiple key usage in the context of
TLS:

Karthikeyan Bhargavan, Cedric Fournet, Markulf Kohlweiss, Alfredo Pironti,
Pierre-Yves Strub, and Santiago Zanella-Beguelin. Proving the TLS
Handshake Secure (as it is).
https://www.mitls.org/downloads/Proving_the_TLS_Handshake.pdf


Happy reading.

Cheers

Kenny

On 16/01/2014 17:37, "Paul Lambert" <paul@marvell.com> wrote:

>Hi Rene,
>
> ⨳|-----Original Message-----
> ⨳|From: Rene Struik [mailto:rstruik.ext@gmail.com]
> ⨳|Sent: Thursday, January 16, 2014 2:31 PM
> ⨳|To: David McGrew; Igoe, Kevin M.; Paul Lambert; Watson Ladd
> ⨳|Cc: Yaron Sheffer; cfrg@irtf.org
> ⨳|Subject: Keys for multiple cryptographic uses (was: Re: [Cfrg] Outline
> ⨳|-> was Re: normative references)
> ⨳|
> ⨳|Hi Paul et al:
> ⨳|
> ⨳|A counter example in practice to the "received wisdom" not to reuse
> ⨳|public keys both for key agreement and non-repudiation is during
> ⨳|certification requests, when the key to be certified is to be used for
> ⨳|uses including key agreement and where the request is signed.
> ⨳|
> ⨳|[see also NIST SP 800-56a-2013, Section 5.6.3.2, item #5:
> ⨳|A static key pair may be used in more than one key-establishment
> ⨳|scheme.
> ⨳|However, one static public/private key pair shall not be used for
> ⨳|different purposes (for example, a digital signature key pair is not
> ⨳|to be used for key establishment or vice versa) with the following
> ⨳|possible
> ⨳|exception: when requesting the (initial) certificate for a public
> ⨳|static key-establishment key, the key-establishment private key
> ⨳|associated with the public key may be used to sign the certificate
> ⨳|request. See SP 800-57, Part 1 on Key Usage for further information.
> ⨳|]
> ⨳|
> ⨳|While key separation seems prudent, it is not entirely clear (to me)
> ⨳|whether the conditions under which this is required are precisely
> ⨳|known (even in the above-mentioned case of signed certificate
> ⨳|requests).[ ⨳] 
>
>Yes - exactly!   Caution is good ... but once this guidance was set down
>we have not bothered to investigate deeply which algorithm combinations
>are secure for mixed use.
>
>Additional wisdom on where specific Oracle exist would be very
>informative.
>
>Thanks,
>
>Paul
>
>
> ⨳|
> ⨳|Best regards, Rene
> ⨳|
> ⨳|
> ⨳|On 1/16/2014 3:30 PM, David McGrew wrote:
> ⨳|> Hi Kevin, Paul, and Watson,
> ⨳|>
> ⨳|> On 01/16/2014 02:42 PM, Igoe, Kevin M. wrote:
> ⨳|>> Paul Lambert
> ⨳|>> On Thursday, January 16, 2014 1:43 AM Paul Lambert wrote:
> ⨳|>>
> ⨳|>>> A truly ‘unified' public key system would support both signatures
> ⨳|>>> and key establishment with the same key.
> ⨳|>>>
> ⨳|>> Received wisdom is that using the same key for both key
> ⨳|establishment
> ⨳|>> and signatures is a bad idea.  I believe the concern is that one
> ⨳|>> protocol might be used an Oracle to subvert the other.
> ⨳|>
> ⨳|> Agreed on that point, but there is a background issue here that I
> ⨳|want
> ⨳|> to ask about.
> ⨳|>
> ⨳|> [snip]
> ⨳|
> ⨳|
> ⨳|--
> ⨳|email: rstruik.ext@gmail.com | Skype: rstruik
> ⨳|cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg