[Cfrg] [CFRG] Dual use (vs key separation) questions

[Dan Brown <[e-mail]>]

Dear CFRG members,

My colleague Alex Truskovsky has brought to my attention the issue of dual use of a single private key (of a public key scheme, e.g. RSA or ECC), where the private key is used for both signing and for key exchange (such as decryption or key agreement).  Some standards address dual use:

1: NIST Special Publication 800-57 forbids a dual use with one exception: a key exchange private key may be used to sign a certificate request.

2: PKIX certificates (a) can be configured to allow or forbid dual use (though this may only apply to the public key side), and (b) when a cert for key exchange key forbids "dual use", a signed certificate request is also forbidden.

Restrictions against dual use are usually called key separation.  Above, 1 is key separation (with exception), and 2b is key separation (when the cert asks for it).

Questions (not necessarily independent):

So, in terms of "dual use", NIST and PKIX are not totally aligned.  Should there be better alignment?  For example, should PKIX move towards NIST by hardening (a) to forbid dual use, and softening (b) to allow dual use signed cert requests?

Are there scheme-generic attacks of dual use?  Of course, dual use introduces a potential risk, which can be shown by using a contrived pathological example, in which any use of the signature scheme reveals the private, but I am asking here if there is an attack that applies for schemes, even when both schemes are secure.

Dual use raw RSA, i.e. without padding, is subject to some severe attacks: (i) chosen-ciphertext forgery, where a signature is forged using a decryption oracle, and (ii) chosen-message decipherment, where a challenge ciphertext is deciphered using a signing oracle, because decryption and signing are the same operation in raw RSA.  In both attacks the private key owner follows key separation, so key separation prevents these attacks only if done on the public key side.  Are these attacks the main justification for key separation?  Are there any other scheme-specific attacks with dual use?  For example, is there any other attack (e.g. even stronger, not using an oracle for the private key operation, i.e. a more passive attack) on raw RSA?  Is there any attack on any type of padded RSA? (I think I saw one paper on it.) Is there an attack on ECDH and ECDSA dual use?

Security proofs, e.g. for RSA-OAEP, often assume dual use is forbidden.  What security analysis (e.g. proofs) work under "dual use"?  A paper by Paterson does this, and mentions some others, but they seem not to cover the usual IETF schemes?  Does universal composability also address dual use?

Do the current conventional most common suite of public key schemes in IETF sufficiently resist dual attacks? So, is key separation overkill for these schemes?  Or, should key separation be added as precaution, because of a lack of thorough study?

What general expectations should there be for public key schemes regarding dual use?  Suppose a new public key scheme is proposed (e.g. pairing-based, quantum-resistant, homomorphic, etc.). Should developers of application standards, who may be using signatures and encryption at a high level interface allowing algorithm agility, always use key separation to prevent potential dual use attacks?  Or should developers and cryptographers have to keep a sharp eye out for dual use attacks, or else proofs of security against dual use, before considering public key schemes secure?

Best regards,

Daniel Brown

Research In Motion Limited




[cid:image001.gif@01CD457D.C408C4F0]




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.