[Cfrg] [CFRG] Dual use (vs key separation) questions
Dan Brown <dbrown@certicom.com> Fri, 08 June 2012 18:44 UTC
Return-Path: <prvs=750686662e=dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEBC11E80E7 for <cfrg@ietfa.amsl.com>; Fri, 8 Jun 2012 11:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.782
X-Spam-Level:
X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+274ZSEu++Y for <cfrg@ietfa.amsl.com>; Fri, 8 Jun 2012 11:44:11 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38C11E80D3 for <cfrg@ietf.org>; Fri, 8 Jun 2012 11:44:10 -0700 (PDT)
X-AuditID: 0a412830-b7ff56d000003d5c-1e-4fd247f8ec20
Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 90.CE.15708.8F742DF4; Fri, 8 Jun 2012 18:44:09 +0000 (GMT)
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.01.0339.001; Fri, 8 Jun 2012 14:44:08 -0400
From: Dan Brown <dbrown@certicom.com>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Thread-Topic: [CFRG] Dual use (vs key separation) questions
Thread-Index: Ac1Fpq/Et+mFYYSRSwSCB6UjcN4rjw==
Date: Fri, 08 Jun 2012 18:44:08 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5080E01@XMB111CNC.rim.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.246]
Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF5080E01XMB111CNCrimnet_"; type="multipart/alternative"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAJsWRmVeSWpSXmKPExsXC5bjwnO5P90v+BjNWs1oc3dXG4sDosWTJ T6YAxqgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzE zNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bns r2thYWqpa6hkp5vQyZPx7+1PxoLfExgrfiy4x9bAuLu+i5GTQ0LARGLP/kXMELaYxIV769m6 GLk4hAT6mCT2bp0G5WxhlJi96DcjSBWbgKrE/aPnwDpEBJQlpu57yARiCwuYSRzd9ZsJIm4t 8f31PDYIW0/i0Y65YDaLgIrE2VutYHN4BdwkXi2aB2YzCshK7D57HayXWUBc4taT+UwQF4lI PLx4mg3CFpV4+fgfK4StKPHk5DUWiPpORokjL9QhZgpKnJz5hGUCo9AsJKNmISmbhaQMIp4r sW37IUYIW0diwe5PbBC2tsSyha+ZYewzBx4zYYrrSGy+tBNqjqJEW+dsoBouIHspo8Trfxvh hr6de4AJpmhK90P2BYy8qxgFczOKDcwMk/OS9Yoyc/XyUks2MYITkobBDsYJe7UOMQpwMCrx 8OY6XvIXYk0sK67MPcQowcGsJMK7lQkoxJuSWFmVWpQfX1Sak1p8iDEeGLwTmaW4k/OByTKv JN7YwIAcjpI4r93BE/5CAunANJqdmlqQWgSzgYmDE+QCLimRYmAyTC1KLC3JiAel7PhiYNKW amAMWP3eSPEmS1bHzYWdNiEPVyc82cas2d1243bF01aeVZkshXKGT3m5lp+fr7N7yX6xbYJN 75MOONXLx3xcefDm1pVl7xbeEKqx5Yk5qWlq9Vqs8XvM7PsWvK+XF+kHnFqy0LPL4qQ7++nm O5+68pbM04n7vXT1p+5jZvu5bs2svRByQMq5hc1KiaU4I9FQi7moOBEAsR4UwaMDAAA=
Subject: [Cfrg] [CFRG] Dual use (vs key separation) questions
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
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, 08 Jun 2012 18:44:16 -0000
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.
- [Cfrg] [CFRG] Dual use (vs key separation) questi… Dan Brown
- Re: [Cfrg] [CFRG] Dual use (vs key separation) qu… Paterson, Kenny