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

Greg Rose <ggr@seer-grog.net> Fri, 17 January 2014 01:19 UTC

Return-Path: <ggr@seer-grog.net>
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 E61731AC421 for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 17:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 5klOaGiCzMaz for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 17:19:07 -0800 (PST)
Received: from homiemail-a15.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id C3C221A9313 for <cfrg@irtf.org>; Thu, 16 Jan 2014 17:19:07 -0800 (PST)
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 613A876C069; Thu, 16 Jan 2014 17:18:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=8vRB+677SghFXvZsS7iUSt9FlVU=; b=29+bX22AM1HahS Tpn6Ua0FH+pXjzSa4eMwbbZWY0r62ksEraqsFYunlbC3cznDCH4wlah7b0nNCRPv Jko0z3xlN8MpokR93dVyZLsE6htZgPxdAPps+ZqjZl4JjzE23mofKWatScyuB4CV RVyWRwTGQhhQzDgu7/Gqv3T0Cj9jI=
Received: from [192.168.20.166] (unknown [64.73.250.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 32F6F76C065; Thu, 16 Jan 2014 17:18:46 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Greg Rose <ggr@seer-grog.net>
In-Reply-To: <CEFDCB1C.13EFA%kenny.paterson@rhul.ac.uk>
Date: Thu, 16 Jan 2014 17:18:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <77DC6B71-2503-43DB-933D-D2277D424885@seer-grog.net>
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> <CEFDCB1C.13EFA%kenny.paterson@rhul.ac.uk>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
X-Mailer: Apple Mail (2.1827)
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>, David McGrew <mcgrew@cisco.com>
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: Fri, 17 Jan 2014 01:19:11 -0000

The same key is used in GSM phones no matter which A5 algorithm is used. The algorithm can change with base stations. Two of the algorithms are breakable in real time (i.e. quickly enough not to break the connection).

Greg.

On Jan 16, 2014, at 14:57 , Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:

> 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
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg


Greg.

Phone: +1 619 890 8236 
secure voice / text: Seecrypt +28131139047 (referral code 54smjs if you want to try it).
PGP: 09D3E64D 350A 797D 5E21 8D47 E353 7566 ACFB D945 (id says ggr@usenix.org, but don’t use that email)