Re: [Cfrg] Keys for multiple cryptographic uses

[Rene Struik <[e-mail]>]

Hi Kenny:

Another useful reference is the Indocrypt2009 paper "Reusing Static Keys 
in Key Agreement Protocols" by Sanjit Chatterjee, Alfred Menezes, and 
Berkant Ustaoglu. This being said, it seems you concur that the picture 
is complicated and that the precise conditions under which key 
separation is required are not exactly known (my original note to Paul 
Lambert's practical question [and discussed as motivation in your 
2011-486 ePrint]).

Best regards, Rene


On 1/16/2014 5:57 PM, Paterson, Kenny 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" <[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: [phone] | US: [phone]
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]