From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751767AbcFWFHS (ORCPT ); Thu, 23 Jun 2016 01:07:18 -0400 Received: from mail.eperm.de ([89.247.134.16]:38032 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912AbcFWFHQ (ORCPT ); Thu, 23 Jun 2016 01:07:16 -0400 From: Stephan Mueller To: Mat Martineau Cc: Tadeusz Struk , dhowells@redhat.com, herbert@gondor.apana.org.au, linux-api@vger.kernel.org, marcel@holtmann.org, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, dwmw2@infradead.org, davem@davemloft.net Subject: Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Date: Thu, 23 Jun 2016 07:07:05 +0200 Message-ID: <3250613.UAo0YkFYZb@tauon.atsec.com> User-Agent: KMail/4.14.10 (Linux/4.4.9-300.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: <20160515041645.15888.94903.stgit@tstruk-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, 22. Juni 2016, 15:45:38 schrieb Mat Martineau: Hi Mat, > > > > Ok, I'll update the patch. > > Thanks, that helps (especially with pkcs1pad). Tadeusz received the updated patch from me to integrate it into his patch set. > > This brings me to another proposal for read buffer sizing: AF_ALG akcipher > can guarantee that partial reads (where the read buffer is shorter than > the output of the crypto op) will work using the same semantics as > SOCK_DGRAM/SOCK_SEQPACKET. With those sockets, as much data as will fit is > copied in to the read buffer and the remainder is discarded. > > I realize there's a performance and memory tradeoff, since the crypto > algorithm needs a sufficiently large output buffer that would have to be > created by AF_ALG akcipher. The user could manage that tradeoff by > providing a larger buffer (typically key_size?) if it wants to avoid > allocating and copying intermediate buffers inside the kernel. How shall the user know that something got truncated or that the kernel created memory? Ciao Stephan