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


Groups > linux.kernel > #1423768

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

From Stephan Mueller <smueller@chronox.de>
Newsgroups linux.kernel
Subject Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
Date 2016-06-16 10:10 +0200
Message-ID <rKAxc-5MU-9@gated-at.bofh.it> (permalink)
References <rzg8R-u7-93@gated-at.bofh.it> <rJOVz-hL-1@gated-at.bofh.it> <rJRgJ-1Ld-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski:

Hi Andrew,

> > 
> > I think we have agreed on dropping the length enforcement at the interface
> > level.
> 
> Separately from this there's a problem with the user being unable to
> know if the algorithm is going to fail because of destination buffer
> size != key size (including kernel users).  For RSA, the qat
> implementation will fail while the software implementation won't.  For
> pkcs1pad(...) there's currently just one implementation but the user
> can't assume that.

If I understand your issue correctly, my initial code requiring the caller to 
provide sufficient memory would have covered the issue, right? If so, we seem 
to have implementations which can handle shorter buffer sizes and some which 
do not. Should a caller really try to figure the right buffer size out? Why 
not requiring a mandatory buffer size and be done with it? I.e. what is the 
gain to allow shorter buffer sizes (as pointed out by Mat)? So, bottom line, I 
am wondering whether we should keep the algif_akcipher code to require a 
minimum buffer size.

If there is really a good argument to allow shorter buffers, then I guess we 
need an in-kernel API call (which should be reported to user space) which 
gives us the smallest usable buffer size. I guess that call would only be 
valid after a setkey operation as the output size depends on the key size. 
Instead of inventing a complete new API call, shouldn't the call 
crypto_akcipher_maxsize() be converted for this purpose? I requested that API 
call during the time the akcipher API was developed explicitly for getting the 
minimum buffer size the caller needs to provide.

Ciao
Stephan

Back to linux.kernel | Previous | NextPrevious 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