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

[Paul Lambert <[e-mail]>]

]-----Original Message-----
]From: Paul Lambert
]Sent: Thursday, January 16, 2014 6:54 PM
]To: Paterson, Kenny
]Cc: Rene Struik; David McGrew; Igoe, Kevin M.; Watson Ladd; Yaron
]Sheffer; [e-mail]; 'Greg Rose'
]Subject: RE: [Cfrg] Keys for multiple cryptographic uses (was: Re:
]Outline -> was Re: normative references)
]
]
]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?
Specifically static ECDH ...

]
]
]]On Jan 16, 2014, at 14:57 , Paterson, Kenny <[e-mail]>
]]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" <[e-mail]> wrote:
]]>
]]>> Hi Rene,
]]>>
]]>> ⨳|-----Original Message-----
]]>> ⨳|From: Rene Struik [mailto:[e-mail]] ]>> ⨳|Sent:
]Thursday, January 16, 2014 2:31 PM ]>> ⨳|To: David McGrew; Igoe, Kevin
]M.; Paul Lambert; Watson Ladd ]>> ⨳|Cc: Yaron Sheffer; [e-mail] ]>>
]⨳|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: [e-mail] | Skype: rstruik ]>> ⨳|cell: +1 (647)
]867-5658 | US: [phone] ]>> ]>>
]_______________________________________________
]]>> Cfrg mailing list
]]>> [e-mail]
]]>> http://www.irtf.org/mailman/listinfo/cfrg
]]>
]]> _______________________________________________
]]> Cfrg mailing list
]]> [e-mail]
]]> http://www.irtf.org/mailman/listinfo/cfrg
]]
]]
]]Greg.
]]
]]Phone: [phone]
]]secure voice / text: Seecrypt [phone] (referral code 54smjs if you
]]want to try it).
]]PGP: 09D3E64D 350A 797D 5E21 8D47 E353 7566 ACFB D945 (id says
]][e-mail], but don’t use that email)