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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 4 Feb 2021 16:26:13 -0800
From:   Eric Biggers <>
To:     Thara Gopinath <>
Subject: Re: [PATCH v5 05/11] crypto: qce: skcipher: Return error for zero
 length messages

On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote:
> > > @@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct skcipher_request *req, int encrypt)
> > >   	rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
> > >   	keylen = IS_XTS(rctx->flags) ? ctx->enc_keylen >> 1 : ctx->enc_keylen;
> > > +	/* CE does not handle 0 length messages */
> > > +	if (!req->cryptlen)
> > > +		return -EOPNOTSUPP;
> > > +
> > 
> > For the algorithms in question, the correct behavior is to return 0.
> What do you mean? The driver should return a 0 ?

Yes, there is nothing to do for empty inputs, so just return 0 (success).

> > Aren't the tests catching that difference?
> I was anyways planning on sending an email to the list with these queries.
> But since you asked,  these are my observations with fuzz testing which I
> have been doing quite a bit now (I am also working on adding a few qualcomm
> AEAD algorithms support in mainline).
> - if the generic algorithm supports 0 length messages and the transformation
> I am testing does not, the test framework throws an error and stops.
> - key support mismatch between the generic algorithm vs my algorithm /engine
> also does the same thing.For eg, Qualcomm CE engine does not support any
> three keys being same for triple des algorithms. Where as a two key 3des is
> a valid scenario for generic algorithm(k1=k3). Another example is hardware
> engine not supporting AES192.
> How are these scenarios usually handled ? Why not allow the test framework
> to proceed with the testing if the algorithm does not support a particular
> scenario ?

Omitting support for certain inputs isn't allowed.  Anyone in the kernel who
wants to use a particular algorithm could get this driver for it, and if they
happen to use inputs which the driver decided not to support, things will break.

The way that drivers handle this is to use a fallback cipher for inputs they
don't support.

- Eric

Powered by blists - more mailing lists