Message-ID: <5549FB94.6020601@freescale.com>
Date: Wed, 6 May 2015 14:31:32 +0300
From: =?UTF-8?B?SG9yaWEgR2VhbnTEgw==?= <horia.geanta@freescale.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Tadeusz Struk <tadeusz.struk@intel.com>, <herbert@gondor.apana.org.au>
CC: <corbet@lwn.net>, <keescook@chromium.org>, <qat-linux@intel.com>,
        <jwboyer@redhat.com>, <richard@nod.at>, <d.kasatkin@samsung.com>,
        <linux-kernel@vger.kernel.org>, <steved@redhat.com>,
        <dhowells@redhat.com>, <vgoyal@redhat.com>,
        <james.l.morris@oracle.com>, <jkosina@suse.cz>,
        <zohar@linux.vnet.ibm.com>, <davem@davemloft.net>, <jdelvare@suse.de>,
        <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
References: <20150430223647.10157.82156.stgit@tstruk-mobl1>
 <55477111.2050803@freescale.com> <5547D9A3.9060800@intel.com>
In-Reply-To: <5547D9A3.9060800@intel.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2015 11:31:42.8688
 (UTC)
X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d;Ip=[192.88.158.2];Helo=[az84smr01.freescale.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB385
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2008
Lines: 51

On 5/4/2015 11:42 PM, Tadeusz Struk wrote:
> Hi Horia,
> On 05/04/2015 06:16 AM, Horia Geantă wrote:
>>> 	int (*sign)(struct pke_request *pkereq);
>>>> 	int (*verify)(struct pke_request *pkereq);
>>>> 	int (*encrypt)(struct pke_request *pkereq);
>>>> 	int (*decrypt)(struct pke_request *pkereq);
>> Where would be the proper place for keygen operation?
> 
> This will need to be extended to support keygen.
> 
>>
>> AFAICT algorithms currently map to primitives + encoding methods, which
>> is not flexible. For e.g. current RSA implementation hardcodes the
>> PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc.
>>
>> One solution would be to map algorithms to primitives only. Encoding
>> methods need to be abstracted somehow, maybe using templates to wrap the
>> algorithms.
> 
> So far there is only one rsa implementation in kernel and it is only used
> by module signing code.
> Later we can add templates or simply one can register "oaep-rsa" algorithm.

I am thinking that it would be more logical for "rsa" to represent only
the *primitives*, for e.g. RSASP1, RSAVP1, RSAEP, RSADP (in rfc3447
terminology).

Then pkcs1_v15(rsa), oaep(rsa), pss(rsa) (i.e. RSAES-PKCS1-v1_5,
RSAES-OAEP, RSASSA-PSS encryption and/or signature schemes) would share
the primitives implementation, the only thing that would differ being
the encoding/padding method.

This is similar to symmetric ciphers convention of having the mode
defined as a wrapper: we have cbc(aes), ctr(aes), gcm(aes) and not
cbc-aes, ctr-aes, gcm-aes.

Another thing to consider is that there might be crypto engines which
are able to perform only "textbook" rsa. This would allow for the
primitives to be offloaded, while the encoding methods would be
performed in SW.

Thanks,
Horia


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/