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

[Paul Lambert <[e-mail]>]

]-----Original Message-----
]From: Watson Ladd [mailto:[e-mail]]
...
]> 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.

Yes ... interested especially with static.
Ephemeral exchanges look like they map well to any ECIES analysis.
Static would leave another dimension of issues ..

Paul

]Sincerely,
]Watson Ladd
]>
]>
]> ]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
]> [phone] | 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)
]>
]
]
]
]--
]"Those who would give up Essential Liberty to purchase a little
]Temporary Safety deserve neither  Liberty nor Safety."
]-- Benjamin Franklin