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

Watson Ladd <watsonbladd@gmail.com> Fri, 17 January 2014 02:56 UTC

Return-Path: <watsonbladd@gmail.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 3B9091ADDCA for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 18:56:57 -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, FREEMAIL_FROM=0.001, MANGLED_MEDS=2.3, 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 xxB5Ek-rdtVp for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 18:56:54 -0800 (PST)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 795961ADD9D for <cfrg@irtf.org>; Thu, 16 Jan 2014 18:56:54 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id b13so3917791wgh.31 for <cfrg@irtf.org>; Thu, 16 Jan 2014 18:56:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=14HA8tni/97zjlbN4w8J2JNTwl8ISWyVy4en1WYtTsg=; b=MKl9hVh8C1lGO4DLRSVeakg73Uk9X1lHsmj7Iyyf9H60d4gU/g0dFhKeZH17NzhjdK gHvV9A712HwdzrUVTGkAoJuM78/SB6biHVeiKmRM1MAkOPdCZWxyUnxWXONRctoMiaAg g+n8we6q3RuIKPTNTBKvlC9iDu6Xrj4s9eLg12Jc73a1ZdfYt2czYld/vW+Sz94Z+RUX 8ZLP9QxfgFNay+ub+lQsFI5Yv6+HGfSN4KXP/rCtIS7TzC5+74DNKHi5NifX2vtg31Cu nPJI+Lb2WRjELNTzvXldGdpEXiIjzsM5C3LVsE3m1HpaiYHhmEWxEtN+lvZZIRGyUCzC m6yw==
MIME-Version: 1.0
X-Received: by 10.180.19.35 with SMTP id b3mr375266wie.20.1389927401757; Thu, 16 Jan 2014 18:56:41 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 16 Jan 2014 18:56:41 -0800 (PST)
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7FB9F7C@SC-VEXCH2.marvell.com>
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> <77DC6B71-2503-43DB-933D-D2277D424885@seer-grog.net> <7BAC95F5A7E67643AAFB2C31BEE662D018B7FB9F7C@SC-VEXCH2.marvell.com>
Date: Thu, 16 Jan 2014 18:56:41 -0800
Message-ID: <CACsn0cki_QqaOYBMkaVTwyL5uq4juectGwE1+WRcX-5mcEKWYg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Yaron Sheffer <yaronf.ietf@gmail.com>, 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 02:56:57 -0000

On Thu, Jan 16, 2014 at 6:53 PM, Paul Lambert <paul@marvell.com> wrote:
>
> Kenny,
>
> Many thanks for the references!
>
> These show a clear path forward to joint key usage with ECC and ECIES!
>
> Do you have any opinions or results (+ or -) on ECDH?

Given what ECIES consists of this should imply ECDH+E-Schnorr works,
but I would not be surprised
if this turns out a bit differently. I'll have to reread the Schnorr
proof to think if the reduction can still work
with an ECDH oracle.
Sincerely,
Watson Ladd
>
>
> ]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
>
> This shows RSA is dangerous for a particular joint use ...
>   In the public key setting, we focus on
>   RSA encryption and signatures, showing a BC attack on
>   RSA-OAEP when it is used in conjunction with an imple-
>   mentation of PKCS#1v1.5 encryption that is vulnerable to
>   Bleichenbacher’s attack [13]. We also remark that a sig-
>   nature forgery attack is possible under the same circum-
>   stances; here we require the same RSA key to be allowed
>   for use in both encryption and signature algorithms
> ]>
> ]>
> ]> 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
>
> RSA Signature Forgery possible in EMV schemes
> ECIES and EC-Schnorr shown secure:
>     More specifically, we prove that the ECIES encryption scheme
>     and the EC-Schnorr signature scheme are jointly secure
>     in the Random Oracle Model, and that ECIES and the
>     EC-DSA signature scheme are jointly secure in the
>     Generic Group Model (GGM). Such results are the best
>     that we can currently hope for, given the state of
>     the art in analyzing ECC signature schemes.
>
> ]>
> ]>
> ]> 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
>
> Interesting ...
>    Extending the ideas of a combined public key
>    scheme, we show how to construct a signcryption
>    scheme which enables a user to use a single keypair
>    for both sender and receiver roles, and which furthermore
>    allows ecient instantiations with short public keys in the standard model
>
>
> Paul
>
> ]>
> ]>
> ]>
> ]> 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)
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin