skcipher and aead API question

skcipher and aead API question

[Pascal Van Leeuwen]

Hi,

Just browsing through include/crypto/skcipher.h and include/crypto/aead.h I noticed that
struct skcipher_alg and struct aead_alg define callbacks named 'init' and 'exit' as well as a
field called 'chunksize'. The inside-secure driver is currently initializing these fields to NULL
or 0 and that appears to work fine, but the respective heade files mention that all fields
should be filled in except for 'ivsize' ...

From the code I deduce that init and exit are not called if they are null pointers, which is
fine for me as I have no need for such callbacks, but can I rely on that going forward?

I also deduce that if chunksize is set to 0, the chunksize will actually be taken from
cra_blocksize, which is at least fine for block ciphers. Again, can I rely on that?
If so, I guess I would  still have to set it for CTR modes which have cra_blocksize is 1?

Finally, I noticed that aead.h defines an additional callback 'setauthsize', which the
driver currently also keeps at NULL and that *seems* to work fine with all current
testmgr tests ... so I do wonder whether that is a must implement or not?
And if so, which subset of auth sizes MUST be implemented?

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

Re: skcipher and aead API question

[Herbert Xu]

On Fri, Jul 05, 2019 at 09:48:53AM +0000, Pascal Van Leeuwen wrote:
> Hi,
> 
> Just browsing through include/crypto/skcipher.h and include/crypto/aead.h I noticed that
> struct skcipher_alg and struct aead_alg define callbacks named 'init' and 'exit' as well as a
> field called 'chunksize'. The inside-secure driver is currently initializing these fields to NULL
> or 0 and that appears to work fine, but the respective heade files mention that all fields
> should be filled in except for 'ivsize' ...
> 
> >From the code I deduce that init and exit are not called if they are null pointers, which is
> fine for me as I have no need for such callbacks, but can I rely on that going forward?
> 
> I also deduce that if chunksize is set to 0, the chunksize will actually be taken from
> cra_blocksize, which is at least fine for block ciphers. Again, can I rely on that?
> If so, I guess I would  still have to set it for CTR modes which have cra_blocksize is 1?

These fields are indeed optional.

> Finally, I noticed that aead.h defines an additional callback 'setauthsize', which the
> driver currently also keeps at NULL and that *seems* to work fine with all current
> testmgr tests ... so I do wonder whether that is a must implement or not?
> And if so, which subset of auth sizes MUST be implemented?

This however must be implemented *if* the underlying algorithm
(IOW refer to the generic implementation) supports them.  The
set of supported values must not be smaller than that of the
generic algorithm.

In practice this shouldn't be a big deal as it's just a matter
of truncating the ICV.

Note that you don't actually need to supply a setauthsize function
if all values (less than maxauthsize are supported).

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

FW: skcipher and aead API question

[Pascal Van Leeuwen]

(+mailing list +davem)
> 
> > Finally, I noticed that aead.h defines an additional callback 'setauthsize', which the
> > driver currently also keeps at NULL and that *seems* to work fine with all current
> > testmgr tests ... so I do wonder whether that is a must implement or not?
> > And if so, which subset of auth sizes MUST be implemented?
> 
> This however must be implemented *if* the underlying algorithm
> (IOW refer to the generic implementation) supports them.  The
> set of supported values must not be smaller than that of the
> generic algorithm.
> 
> In practice this shouldn't be a big deal as it's just a matter
> of truncating the ICV.
> 
Hmmm .... for a HW driver, the HW would have to do the truncation.
So it must be capable of doing that AND it must be instructed to do so.
I guess big deal is a relative term :-)

> Note that you don't actually need to supply a setauthsize function
> if all values (less than maxauthsize are supported).
> 
If I don't implement that function that I cannot tell my HW how the
tag should be truncated ...

> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

FW: skcipher and aead API question

[Pascal Van Leeuwen]

(+mailing list +davem)

> > Hmmm .... for a HW driver, the HW would have to do the truncation.
> > So it must be capable of doing that AND it must be instructed to do so.
> > I guess big deal is a relative term :-)
> 
> Right for decryption you'd need to use a fallback.
> 
Or I need to tell the HW the size of the tag to compare. Which IS possible.

> You really only need to support the truncation lengths for gcm/ccm.
> AFAICS the users of authenc do not use the setauthsize function at
> all.
> 
> We probably should change authenc to disallow setauthsize in case
> somebody starts doing this in future.
> 
Actually, IPsec uses truncated tags for HMAC's ... so it may be useful
to have that there as well. And I would expect/hope the kernel IPSec 
implementation to actually use the authenc template?

> > If I don't implement that function that I cannot tell my HW how the
> > tag should be truncated ...
> 
> You can just read tfm->authsize as that's what the default
> setauthsize function will set.
> 
I was referring to the case where it actually needed to be configurable.

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

FW: skcipher and aead API question

[Pascal Van Leeuwen]

(+mailing list +davem)

> > > You can just read tfm->authsize as that's what the default
> > > setauthsize function will set.
> > >
> > I was referring to the case where it actually needed to be configurable.
> 
> No that's what I meant.  Look at the generic authenc template.
> It supports truncation but doesn't actually provide a setauthsize
> function.
> 
I get it. The callback is only needed to do the checking if you don't support
the full range. Otherwise the value is already conveniently stored for you :-)

> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com