linux-kernel - Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.OSX.2.20.1606221515040.16377@mjmartin-mac01.local>
Date:	Wed, 22 Jun 2016 15:45:38 -0700 (PDT)
From:	Mat Martineau <mathew.j.martineau@...ux.intel.com>
To:	Tadeusz Struk <tadeusz.struk@...el.com>,
	Stephan Mueller <smueller@...onox.de>
cc:	Mat Martineau <mathew.j.martineau@...ux.intel.com>,
	dhowells@...hat.com, herbert@...dor.apana.org.au,
	linux-api@...r.kernel.org, marcel@...tmann.org,
	linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
	linux-crypto@...r.kernel.org, dwmw2@...radead.org,
	davem@...emloft.net
Subject: Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher
 interface

Stephan and Tadeusz,

On Fri, 10 Jun 2016, Tadeusz Struk wrote:

> On 06/09/2016 11:36 AM, Stephan Mueller wrote:
>> Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau:
>>
>> Hi Mat, Tadeusz,
>>
>> Ok, after checking the code again, I think that dropping that sanity check
>> should be ok given that this length is part of the akcipher API.
>>
>> Tadeusz, as you are currently managing that patch set, would you re-spin it
>> with the following check removed?
>>
>> +     if (usedpages < akcipher_calcsize(ctx)) {
>> +             err = -EMSGSIZE;
>> +             goto unlock;
>> +     }
>>
>
> Ok, I'll update the patch.

Thanks, that helps (especially with pkcs1pad).

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.

--
Mat Martineau
Intel OTC