Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421580

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

Show all headers | View raw

Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski:

Hi Andrew,

> Hi,
> 
> On 8 June 2016 at 21:14, Mat Martineau
> 
> <mathew.j.martineau@linux.intel.com> wrote:
> > On Wed, 8 Jun 2016, Stephan Mueller wrote:
> >> What is your concern?
> > 
> > Userspace must allocate larger buffers than it knows are necessary for
> > expected results.
> > 
> > It looks like the software rsa implementation handles shorter output
> > buffers ok (mpi_write_to_sgl will return EOVERFLOW if the the buffer is
> > too small), however I see at least one hardware rsa driver that requires
> > the output buffer to be the maximum size. But this inconsistency might be
> > best addressed within the software cipher or drivers rather than in
> > recvmsg.
> Should the hardware drivers fix this instead?  I've looked at the qat
> and caam drivers, they both require the destination buffer size to be
> the key size and in both cases there would be no penalty for dropping
> this requirement as far as I see.  Both do a memmove if the result
> ends up being shorter than key size.  In case the caller knows it is
> expecting a specific output size, the driver will have to use a self
> allocated buffer + a memcpy in those same cases where it would later
> use memmove instead.  Alternatively the sg passed to dma_map_sg can be
> prepended with a dummy segment the right size to save the memcpy.
> 
> akcipher.h only says:
> @dst_len: Size of the output buffer. It needs to be at least as big as
> the expected result depending on the operation
> 
> Note that for random input data the memmove will be done about 1 in
> 256 times but with PKCS#1 padding the signature always has a leading
> zero.
> 
> Requiring buffers bigger than needed makes the added work of dropping
> the zero bytes from the sglist and potentially re-adding them in the
> client difficult to justify.  RSA doing this sets a precedent for a
> future pkcs1pad (or other algorithm) implementation to do the same
> thing and a portable client having to always know the key size and use
> key-sized buffers.

I think we have agreed on dropping the length enforcement at the interface 
level.

Ciao
Stephan

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Andrew Zaborowski <balrogg@googlemail.com> - 2016-06-14 00:20 +0200
  Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Stephan Mueller <smueller@chronox.de> - 2016-06-14 07:20 +0200
    Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Andrew Zaborowski <balrogg@googlemail.com> - 2016-06-14 09:50 +0200
      Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Stephan Mueller <smueller@chronox.de> - 2016-06-16 10:10 +0200
        Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Andrew Zaborowski <balrogg@googlemail.com> - 2016-06-16 17:00 +0200
          Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Stephan Mueller <smueller@chronox.de> - 2016-06-16 17:40 +0200
            Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Andrew Zaborowski <balrogg@googlemail.com> - 2016-06-17 02:50 +0200

csiph-web