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

Paul Lambert <paul@marvell.com> Fri, 17 January 2014 02:54 UTC

Return-Path: <paul@marvell.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 DB4FD1ADDCA for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 18:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.733
X-Spam-Level:
X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 CaN5A5OFhn0K for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 18:54:11 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id A4E681ADBD4 for <cfrg@irtf.org>; Thu, 16 Jan 2014 18:54:11 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0H2ruKD026732; Thu, 16 Jan 2014 18:53:56 -0800
Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0b-0016f401.pphosted.com with ESMTP id 1heuj0g24u-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jan 2014 18:53:56 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Thu, 16 Jan 2014 18:53:55 -0800
From: Paul Lambert <paul@marvell.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Date: Thu, 16 Jan 2014 18:53:54 -0800
Thread-Topic: [Cfrg] Keys for multiple cryptographic uses (was: Re: Outline -> was Re: normative references)
Thread-Index: Ac8TIhnDyxRZRB8iQUK6a5Oz6V9ULQACKXWQ
Message-ID: <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>
In-Reply-To: <77DC6B71-2503-43DB-933D-D2277D424885@seer-grog.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-17_01:2014-01-16, 2014-01-17, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401160199
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:54:14 -0000

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?


]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)